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Hardware 


Exploring File Server 
Performance 

Gregg McKnight and Avery Lyford 
IBM Corporation 
Boca Raton, Florida 

File servers are specifically designed to handle large volumes of input!out¬ 
put, and sometimes heavy use of the processor. These two requirements 
conflict - emphasis on one usually degrades the performance of the other. 
These issues influenced the design of the IBM PS/2® Model 95 486 50 
MHz Server. This article discusses the 50 MHz sewers dual-bus design, 
streaming data protocol, processor cache, Error Checking and Correc¬ 
tion (ECC) memory, disk subsystem, and network subsystem. It also com¬ 
pares the performance of the IBM PS/2 Model 95 486 50 MHz Server with 
the performance of other manufacturers file sewer systems. 



L ocal Area Network (LAN) tech¬ 
nology enables personal com¬ 
puters, as well as minicomputers 
and mainframe systems, to share 
information. In a LAN environment, 
a powerful file server provides data 
storage and resource sharing to other 
computers called clients , which are 
attached to the LAN. A typical PC 
server is a high-performance 80386- 
or 80486-based computer with large 
disk capacity, a high-performance 
network adapter, and a network 
operating system. 

Most file servers evolved from 
desktop systems that were originally 
intended to function as stand-alone 
computers. These servers have perfor¬ 
mance problems. File servers must 
manage an enormous number of 
Input/Output (I/O) requests, in con¬ 
trast to most stand-alone systems, 
which perform relatively little I/O. 
The evolution in processor speed 
from the 8088-based IBM Personal 
Computer to today’s 80486-based 
systems has been accompanied by 
more than a tenfold increase in proc¬ 
essor performance. However, the per¬ 
formance of disks, network adapters, 
and I/O buses has not kept pace with 
processor performance. As a result, 
most desktop systems are not well 
suited for file-serving applications. 

There is a major difference in the 
requirements of database servers and 
file servers. A file server must move 
large amounts of data rapidly, whereas 
a database server must have a proces¬ 
sor that can manipulate large tables 
of records and indexes. Database 
servers stress the server’s processor, 
whereas file servers place more stress 
on the network. Both stress the disk 
subsystems. 
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Besides being used as file servers, 
personal systems are used as data¬ 
base, electronic mail, and communi¬ 
cation servers. In these client/server 
environments, application processing 
is divided between the client work¬ 
station and the server. For example, 
rather than requesting an entire file 
in order to update only one record, 
a database client requests only the 
required record. The server interprets 
this request, retrieves the record, and 
passes it to the client. The server is, 
therefore, responsible for record 
searching. This increases the utili¬ 
zation of the server’s disks and proc¬ 
essor, which in turn decreases LAN 
traffic. 

Server Performance 
Requirements 

Developing a system that can handle 
many I/O operations, while providing 
high-performance processing and 
enhanced reliability, presents several 
complex design problems: 

Availability. Servers are increasingly 
being used in mission-critical applica¬ 
tions, where down time can be very 
costly. 

Memory. Servers require vast 
amounts of memory for the network 
operating system, File Allocation 
Tables (FATs), disk cache, and 
network I/O buffers. 

Reliability. More memory means a 
greater chance of a memory failure 
that could bring down the server. 
Reliability, therefore, means that the 
server must continue to function even 
though it requires significantly more 
memory than a PC. 

File servers are I/O engines. Naturally, 
a faster processor increases the num¬ 
ber of instructions that can be proc¬ 
essed in a unit of time. Each I/O 
request that enters a server has an 
associated number of instructions 
that must be executed by its proces¬ 
sor. Thus, processor performance can 


limit the number of I/O requests that 
a server can handle. This limits the 
number of users that the server can 
support. The effect of a faster proces¬ 
sor in a file server is to support more 
users, not to move any single I/O 
operation through the server faster. 

Because file servers are I/O engines, 
the network and disk subsystems 
often play a more important role than 
the processor. Network adapters are 
the doorway to the server. A slow net¬ 
work adapter impedes server perfor¬ 
mance because data cannot get into 
and out of the server fast enough. The 
disk subsystem empties and fills 
memory to satisfy network adapter 
requests for data. A slow disk subsys¬ 
tem reduces the useful capacity of 
the server system. When the disk can¬ 
not write data rapidly, memory fills 
quickly with cached write data. When 
this happens, there is no room in mem¬ 
ory to handle data being read from 
the disk into the cache. Read cache 
hit rates begin to degrade as more 
requests have to be serviced directly 
from disk. As additional requests 
enter the server, performance contin¬ 
ues to decline because fewer requests 
can be serviced from the disk cache, 
and most requests go directly to the 
disk subsystem. At this point, all 
client I/O requests must wait for the 
slow disk subsystem to read and 
write information. As a result, the 
overall performance of the server is 
significantly reduced. 

Ideally, an efficient server should have 
a processor that offers performance 
matched to the number of users and 
the types of I/O requests performed. 
Furthermore, fast network and disk 
subsystems are critical for moving 
data through the server without delay. 

Busmaster I/O 
Performance Interference 

High-performance servers typically 
employ busmaster network and disk 
adapters. A busmaster adapter is 
advantageous because it can move 


information to and from memory on 
its own behalf, without involving the 
system processor. In contrast, a non- 
busmaster adapter requires the proc¬ 
essor to coordinate the data transfer. 
The ability of a busmaster to perform 
unassisted data transfers improves 
the efficiency of a server and enables 
it to support an increased workload, 
additional users, or both. 

As busmaster adapters handle larger 
quantities of information, an inter¬ 
esting phenomenon occurs. As the 
busmaster uses more memory band¬ 
width, it reduces the processor’s 
ability to access memory during in¬ 
struction fetch cycles. For example, 
in some systems, busmasters that use 
50% memory bandwidth cause a 
50% decrease in system processing 
power. This means that the processor 
is spending 50% of its time waiting 
to access memory, so that it can sus¬ 
tain only half of its original instruc¬ 
tion processing performance. 

Two factors, therefore, contribute to 
increased processor utilization and 
increased file server workload. First, 
an increase in I/O operations typically 
causes an increase in processor work¬ 
load, because each I/O operation 
requires some processing. Second, 
the busmaster I/O interferes with the 
processor’s ability to execute instruc¬ 
tions. The more information handled 
or the more I/O operations performed 
by the busmaster adapter, the greater 
the amount of interference that the 
processor encounters as it tries to 
access the same memory space. The 
result is that server capacity decreases 
in poorly designed systems. 

Figure 1 shows how the processor 
and I/O adapters compete for mem¬ 
ory access in conventional server 
systems. 

IBM PS/2 Model 95 486 50 
MHz Server Performance 

The IBM PS/2 Model 95 486 50 
MHz Server conquers the I/O band- 
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Figure 1. Processor and I/O Adapter Contention for Memory Access 



Figure 2. Improved I/O Performance with Dual-Bus Technology 


width interference problem with a 
unique system design. This design 
provides a “dual bus” - independent 
memory paths for the processor and 
busmaster devices. Therefore, the per¬ 
formance of the new design (shown 
in Figure 2) is significantly improved 
over the performance of conventional 
personal computers used as servers. 
Under heavy workloads, the PS/2 
Model 95 486 50 MHz Server offers 
superior performance, while the per¬ 
formance of most PC servers would 
severely degrade. 

In addition to its dual-bus capability, 
the 50 MHz server’s performance is 
also enhanced because it supports the 
Micro Channel® 40 MB streaming 
data protocol. Busmaster adapters 
designed to support the 40 MB 
streaming data protocol greatly im¬ 
prove data throughput. For example, 
the IBM 16/4 Token-Ring Busmaster 
Adapter/A installed in a PS/2 Model 
80-311 can transfer data at a rate of 
up to 6.6 MB/second over the Micro 
Channel. The same token-ring adapt¬ 
er in the 50 MHz server can transfer 
data up to 20 MB/second. A 32-bit 
token-ring adapter with streaming 
data support can transfer data up to 
40 MB/second. 

A processor cache is standard in the 
50 MHz server. The cache is required 
in the advanced design of the mem¬ 
ory controller in the 50 MHz server 
and improves processor efficiency up 
to 2.24 times. 

A new 32-bit Direct Memory Access 
(DMA) controller further improves 
system efficiency by supporting the 
Subsystem Control Block (SCB) 
architecture. By defining the inter¬ 
face between two communicating 
devices within a PS/2 system, the 
SCB architecture improves the effici¬ 
ency of software drivers that must 
activate the DMA controller. SCBs 
enable a consistent interface for 
device programming and communi¬ 


cation between various devices and 
system memory. 

Currently, the most popular use for 
the system DMA facility in most PC 
systems is to support floppy diskette 
I/O operations. Most popular adap¬ 
ters use programmed I/O or busmas¬ 
ter data transfers. Thus, the actual 
improvements seen by the 32-bit 
DMA controller will vary depending 
on the application. 


Standard features of the PS/2 Model 
95 486 50 MHz Server include 16 
MB of Error Checking and Correc¬ 
tion (ECC) memory, a 2.88 MB 3.5- 
inch diskette drive, 256 KB of Level 
2 cache, a new Small Computer 
Systems Interface (SCSI) controller 
designed to improve client through¬ 
put up to 23% over older SCSI 
adapters, a 32-bit Extended Graphics 
Array (XGA™) busmaster adapter. 


PERSONAL SYSTEMS / OCTOBER 1992 




































































4 


and either a 400 MB or 1 GB SCSI 
hard drive. 

Increased Server Reliability 

Customers are demanding increased 
server system reliability. Many server 
outages can be attributed to memory 
failures. Servers have substantially 
more memory than most desktop 
systems. The potential for memory- 
related outages increases when there 
is more memory, so servers are par¬ 
ticularly susceptible to memory 
failures. To alleviate this problem, 
additional reliability features were 
designed into the 50 MHz server’s 
processor complex. These features 
include support for both parity mem¬ 
ory and ECC memory, although only 
one kind of memory can be used in a 
system at a time. 

Conventional servers have only parity 
memory. Parity memory can detect 
only single-bit errors, and all process¬ 
ing stops when an error is detected. 
ECC memory also detects single-bit 
errors, but then the ECC circuitry cor¬ 
rects the error and allows processing 
to continue. Of course, the computer 
stores the address of the failing mem¬ 
ory location in a log. The log tells the 
system administrator that an error has 
occurred, so the administrator can 
eventually replace that memory 
module. 

In addition, ECC memory technology 
can detect rare double-bit errors and 
some triple- and quadruple-bit errors. 
The ECC memory checking design 
of the 50 MHz server has little effect 
on system performance; throughput 
is, at most, only a few percentage 
points lower than with parity checking. 

The 50 MHz server also has a facility 
that checks for data transmission 
errors over the Micro Channel. This 
facility, called Micro Channel Data 
Parity Checking , enables busmaster 
adapters to check for accurate data 


transfers over the Micro Channel. 

This checking is important because 
the probability of a data error in¬ 
creases as the speed of transfer over 
the Micro Channel increases. It is 
interesting to note that the Extended 
Industry Standard Architecture 
(EISA) design specification does not 
include accuracy checking of data 
that is passed through an EISA bus. 

It is possible that a bus transfer error 
will never be detected in an EISA 
computer. 

Besides its Micro Channel Data Par¬ 
ity Checking facility, the 50 MHz 
server goes one step further by pro¬ 
viding a facility called Synchronous 
Channel Check. This facility allows 
the collection of information that will 
help the operating system recover 
from busmaster adapter errors. Syn¬ 
chronous Channel Check lets an 
operating system know exactly which 
cycle the busmaster was attempting 
when an error occurred. With this in¬ 
formation, the operating system can 
make intelligent choices about retry¬ 
ing the operation or halting the sys¬ 
tem. In previous computers, when a 
busmaster adapter detected an error, 
it signaled the computer using the 
channel check line. However, this 
signal was activated some time after 
the actual error occurred. Conse¬ 
quently, there was no choice other 
than to completely halt processing 
when an adapter error is detected. 

No conventional computer system - 
based on Industry Standard Architec¬ 
ture (ISA) or EISA bus designs - 
offers recovery from busmaster adapt¬ 
er errors, because it is not part of the 
architectural definition for those 
buses. 

Comparison with Other 
Architectures 

Most manufacturers of ISA and 
EISA systems do not offer system 
upgrades for ECC memory support, 
faster I/O bus speeds, and improved 


DMA performance, because the inte¬ 
grated circuits required to implement 
these changes are soldered into the 
planar board of the systems. Most 
ISA and EISA system manufacturers 
claim upgradable processor com¬ 
plexes, but they provide an upgrade 
path only for the processor and 
cache. The EISA specification does 
not even accommodate faster cycles; 
the current EISA specification limits 
throughput to 33 MB per second. The 
IBM PS/2 Model 95 processor com¬ 
plex strategy enables users to upgrade 
existing machines to support 40 MB 
per second. Furthermore, the Micro 
Channel architecture defines rates of 
80 MB and 160 MB per second. 

All critical integrated circuits of the 
IBM PS/2 Models 90 and 95 are lo¬ 
cated on the processor complex. This 
gives these PS/2 owners a migration 
path that improves not only processor 
performance, but also Micro Chan¬ 
nel, DMA controller, and memory 
controller performance and function. 

50 MHz Server Disk 
Subsystem Performance 

Several advanced features in the 
design of the disk subsystem in the 
50 MHz server have brought a signifi¬ 
cant improvement in disk subsystem 
performance. The 50 MHz server’s 
disk subsystem has a much-improved 
32-bit caching controller. This device 
does not support data streaming, but 
it offers significantly improved net¬ 
work user throughput compared to 
the 32-bit caching controller found in 
previous PS/2 systems. 

The microprocessor on the new SCSI 
subsystem executes SCSI microcode 
faster. Faster adapter memory enables 
the microprocessor to access memory 
with fewer wait states. Also, the SCSI 
interface chip has been replaced with 
an IBM-developed SCSI chip that 
reduces SCSI processing overhead. 
Each of these changes helps the new 
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32-bit SCSI adapter with cache to 
process up to 23% more user requests 
per second. Finally, a SCSI bus ter¬ 
minator has been added on the card, 
removing the requirement for the 
bulky external SCSI bus terminators. 

50 MHz Server Network 
Subsystem Performance 

The IBM 16/4 Token-Ring Busmaster 
Adapter/A supports the streaming 
data mode. In streaming data mode 
on the 50 MHz server, the throughput 
of a single 16/4 Token-Ring Bus- 
master Adapter increases up to 17% 
compared to throughput on the 33 
MHz PS/2 Model 95. Performance 
increases even more when multiple 
token-ring adapters are used. 

Using a 32-bit busmaster streaming 
data Token-Ring adapter that is avail¬ 
able later this year, the 50 MHz server 
offers up to three times the network 
throughput as a 33 MHz PS/2 Model 
95. This new adapter technology 
allows the full performance of the 
50 MHz server to be realized. Soon, 
additional adapters such as high- 
performance Ethernet™, disk, and 
other network adapters will be avail¬ 
able, further enhancing the perfor¬ 
mance of the 50 MHz server. 

User Benefits 

Technical terms, such as improved 
busmaster throughput, processor per¬ 
formance, ECC memory, and Micro 
Channel data checking, describe the 
advanced attributes of the 50 MHz 
server system. But what do these 
technical advances mean to users? 
The best way to illustrate how users 
benefit from design improvements in 
the 50 MHz server is to present the 
results of comparing the 50 MHz 
server against well-known servers 
from other manufacturers. 


Comparison with COMPAQ® 
SystemPro® 486/33: The SCSI disk 
subsystem in the IBM Model 95 486 
50 MHz Server has a total through¬ 
put up to 19.4% greater than the Intel¬ 
ligent Drive Array (IDA) controller 
in the COMPAQ SystemPro 486/33. 
Throughput was measured at the 
client systems while each server was 
running Novell® NetWare® 3.11 and 
was under a heavy workload. The 
IBM and COMPAQ systems had the 
same number of drives, and no data 
guarding was used. 

Comparison with Dell® System 
450SE: Compared to the Dell Drive 
Array, the IBM SCSI disk subsystem 
in the 50 MHz server yielded up to 
326% greater throughput. In this 
instance, the Dell Drive Array disk 
subsystem was configured in the 
composite mode as recommended in 
the documentation supplied with the 
Dell System 450SE. When the Dell 
Drive Array was configured in a 
fault-tolerant or data-guarding mode, 
the IBM SCSI disk subsystem pro¬ 
vided up to 377% more throughput. 

Conclusion 

In LAN file-server environments, the 
overall system design and balance are 
of paramount importance. The subsys¬ 
tem components in the PS/2 Model 
95 486 50 MHz Server - high-speed 
I/O bus, error-correcting memory, 
and dual-bus memory architecture - 
were designed to respond to these re¬ 
quirements. The 50 MHz server sup¬ 
ports large amounts of memory and 
avoids the down time that results 
from frequent memory failures. High- 
performance disk subsystems, with 
advanced Micro Channel and ECC 
memory features, increase potential 
capacity to several hundred simultan¬ 
eous users. Also, the 50 MHz server 


is designed to handle higher band¬ 
width applications such as multimedia. 

This article is adapted from an 
article appearing in Issue 2, 1992 of 
Innovations, an IBM Boca Raton 
publication for employees. 
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PS/2 3.5-Inch Rewritable 
Optical Drive 

Pedro L. Martinez 
IBM Corporation 
Boca Raton, Florida 

This article discusses the technology of the IBM PS/2 3.5-inch rewritable 
optical drive , its advantages over other storage device technologies , the 
applications it supports , and its capacity for storing user data. 


T he IBM PS/2 3.5-inch rewritable 
optical drive provides an excel¬ 
lent platform for supporting a 
broad range of today’s applications. 
More important, it enables a new gen¬ 
eration of possibilities never realized 
by a personal computer, including 
the “paperless office” and multi- 
media. 

The PS/2 3.5-inch rewritable optical 
drive is the first PS/2 optical drive 
that offers both read and write capa¬ 
bility. Because of its high capacity 
and removability, it is a functional, 
flexible, secure device. 

Highlights 

The highlights of the rewritable opti¬ 
cal drive point out the advantages of 
its leading-edge technology: 

• The single-sided removable disk is 
compact, portable, and securable. 

• Its 3.5-inch, half-height form 
factor is consistent with today’s 
smaller desktop computers. 

• The 127 MB read/write media 
enables the equivalent of a large 
hard disk to be carried in a pocket 
or purse. 

• The 122 MB read-only media is 
the ideal capacity and form factor 
for mass distribution applications. 

• Both rewritable media and read¬ 
only media can be read by the 
same drive. 


• The Small Computer Systems 
Interface (SCSI) is the newest 
industry-standard interface for 
attaching storage and peripheral 
devices. 

• OS/2® and DOS support give the 
rewritable optical drive the sup¬ 
port of the most popular operating 
systems today. 

• The media, compatible with the 
American National Standards Insti¬ 
tute (ANSI®) industry standard, 
was designed to industry standards 
that preserve the interchangeabil¬ 
ity of media among compliant 
manufacturers. 

Magneto-Optic Technology 

The technology that the PS/2 3.5- 
inch rewritable optical drive uses to 
perform read and write operations is 
called magneto-optics . As the name 
implies, it involves two technologies: 
electromagnetics and optics. The 
media is composed of metal particles 
that are sensitive to magnetic fields 
and are sandwiched between noncon- 
ductive coatings. The entire disk is 
then enclosed with a plastic casing as 
on a 3.5-inch diskette. 

Figure 1 shows the basic components 
of magneto-optic technology. They 
include particles of metal in the media, 
a laser beam, and an electromagnet. 

The state of the components before 
recording on the media is shown on 


the left of Figure 1. New media is 
shipped with all values at 0. When it 
is read, it reflects the laser light polar¬ 
ized (rotated) in a counterclockwise 
direction. This polarity represents the 
stored value 0. 

To perform a write operation, the par¬ 
ticles of metal are oriented either per¬ 
pendicular to the disk surface, which 
represents binary value 0, or horizon¬ 
tally, representing a binary 1 value. 

(In Figure 1, to distinguish vertical 
from horizontal particles, all particles 
are drawn vertically with directional 
arrows. Particles that point upward 
are the true perpendicular particles, 
with value 0. Particles that point 
downward represent horizontal par¬ 
ticles, with value 1.) To acquire one 
of these two orientations, a particle is 
heated by a direct laser beam to 150 
degrees Celsius. At that temperature, 
the particle becomes susceptible to 
magnetic fields. Next, an electro¬ 
magnet is applied to the particle. The 
combination of the laser heat and the 
electromagnet sets the polarity (the 
direction) of the particle. The particle 
then cools and maintains that orienta¬ 
tion. This is illustrated in the middle 
diagram in Figure 1. 

The read operation, shown on the 
right of Figure 1, is much simpler. 

The laser beam is applied with much 
lower intensity when aimed at a par¬ 
ticle. If the particle reflects the laser 
light in one direction, it represents 
the binary value 1; if it reflects laser 
light in the opposite direction, it rep¬ 
resents the binary value 0. The particle 
shown between the electromagnet 
and the laser beam in Figure 1 reflects 
the laser light polarized in a clock¬ 
wise direction, which represents the 
value 1. 

The write and read operations occur 
remarkably fast, since the drive is 
spinning at over 1,800 rotations per 
minute. 
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Figure 1. Components of Magneto-Optic Technology 


There are several advantages to 
magneto-optic recording. The data 
cannot be altered by stray magnetic 
fields or inadvertent exposure to mag¬ 
nets. Disk crashes are eliminated, be¬ 
cause the recording mechanism does 
not fly as close to the media as with 
hard disks. Compared to CD-ROM 
and Write Once/Read Many (WORM) 
drives, magneto-optics have been 
tested to one million rewrites. The 
media is so stable that IBM warrants 
it for seven years. 

Optical Read-Only Memory 

The 3.5-inch rewritable optical drive 
can read a second type of media, 
called Optical Read-Only Memory 
(O-ROM). As with CD-ROM, the data 
is “stamped” onto O-ROM instead of 
being written by a drive. Stamping is 
typically done by third-party vendors 
who have sophisticated equipment to 
mass-produce the media. Although 
this process is costly, the cost is off¬ 
set because O-ROM media is less 
expensive than rewritable media, and 
it is being used in large quantities. 
Users can choose to replicate their 
application en masse for large distrib¬ 
ution. For fewer copies, they can 
write the data using the drive itself. 

In either case, the drive is compatible 


with both types of media (O-ROM 
and rewritable) and both types of 
data recording (stamped data and 
written data). 

Compared to CD-ROM, O-ROM is 
the preferred solution for applica¬ 
tions that require speed and interac¬ 
tivity. O-ROM is preferred if the 
drive is used not only for data or pro¬ 
gram distribution, but also to supple¬ 
ment or back up a hard disk. These 
applications illustrate the practical, 
multifunctional capabilities of the 
rewritable optical drive. 

Applications 

The PS/2 3.5-inch rewritable optical 
drive accommodates several state-of- 
the-art software applications, such as 
the following: 

• Microfiche replacement 

• Paperless office 

• Catalog distribution 

• Large, flexible server database 

• Portable database 

• Multimedia presentations 

• Hard disk backup 

• Additional, large storage 


Data or program distribution, data 
portability, large storage, and saving 
and restoring are common user 
requirements. Emerging applications 
such as multimedia and image stor¬ 
age are also natural for this technol¬ 
ogy because the technology is faster, 
denser, removable, faster to replicate, 
and more secure. 

Comparison with Other 
Technologies 

Figure 2 compares the PS/2 rewritable 
optical drive with existing technolo¬ 
gies used in a variety of applications. 
The comparisons show that the rewrit¬ 
able optical drive is an excellent 
multifunctional device that performs 
tasks typically requiring multiple 
devices. 

Storage Capacity 

How much data can be stored in 127 
MB? Here are examples of the amount 
of data that can be stored on one 
PS/2 3.5-inch rewritable optical drive: 

• 88 high-density diskettes 

• 40,000 pages of text 

• 1,200 Video Graphics Array 
(VGA) images 
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Alternative Media 

Optical Advantages 

Optical Highlights 

Characteristic or Function 

Diskette 

Denser 

88 X More Capacity 

Media Distribution 

Portability 


Faster 

1.4 X Average Seek 

11 X Data Rate 

Save/Restore 

Multimedia 


Fast Replication 

Media Stamping 


CD-ROM 

Writable 

Read/Write 

Media Distribution 

Multimedia 


Smaller 

3.5-inch versus 5.25-inch Drive 
3.5-inch versus 4.75-inch Media 



Faster 

6 X Average Access 

2.5 X Data Rate 


1/4-inch Tape 

Faster 

Random Access 

100 X Average Seek 

11 X Data Rate on Read 

3 X Data Rate on Write 

Portability 

Save/Restore 

Media Distribution 


Fast Replication 

Media Stamping 


Multiple Hard Disks 

Removable 

Only One Drive Required 

Mass Storage 


Limitless 


Multimedia 


Enhanced Security 

Removable Media 



Figure 2. Comparison of the PS/2 3.5-Inch Rewritable Optical Drive with Alternative Media 


• 8,000 graphic images (320 x 200 
with 256 colors) 

• 45 minutes of an IBM Audio 
Visual Connection® (AVC) multi- 
media presentation 

• 14 minutes of an IBM Digital 
Video Interactive (DVI®) 
presentation 

• 1.5 hours of high-quality music 

In backup and restore applications, 
the drive can back up a 60 MB hard 
disk in less than 15 minutes. 


Technology Direction 

Rewritable optical technology is 
poised for growth in capacity and per¬ 
formance. Besides techniques for in¬ 
creasing density and reducing access 
time, key enhancements will emerge 
as system support for the technology 
continues to develop. Advancements 
in system architectures, increased use 
of rewritable optical technology as 
computer subsystems, and state-of- 
the-art operating systems and applica¬ 
tions will accelerate the use of 
rewritable optical technology. 


Pedro L . Martinez is the product 
line manager in the marketing 
organization of the IBM Personal 
Systems Line of Business in Boca 
Raton, Florida. Since joining IBM 
in 1975, Pete's work assignments 
have included minicomputer sys¬ 
tem design, advanced technology, 
computer architecture, and man¬ 
agement in robotics, mid-range 
systems, automotive systems, fault- 
tolerant computers, personal 
computers, and technical worksta¬ 
tions. He has a BS in electrical 
engineering from the University 
of Miami. 
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Programming the XGA Video 
POS Registers 

Jim Paolantonio 
IBM Corporation 
Boca Raton, Florida 

Programmable Option Select (POS) registers are an innovative feature in 
PS/2 Micro Channel systems that eliminate the need for manual switches 
on the system board and on adapter cards. As the name implies , these 
registers must be programmed. This article discusses programming the 
POS registers on the XGA Display Adapter. It gives details about the con¬ 
tents of each register , and shows how the system puts these contents to use. 


T he XGA Display Adapter pro¬ 
vides high-resolution graphics 
(1024 x 768 with 256 colors) 
along with Video Graphics Array 
(VGA) mode operation. In the 
Extended Graphics Array (XGA) 
graphics mode, the XGA adapter’s 
graphics coprocessor supports hard¬ 
ware drawing assist functions: BitBLT 


(Video Bitmap Block Transfer), line 
drawing, and area fill. These func¬ 
tions are optimized for use with the 
Microsoft® Windows® and OS/2 
Presentation Manager® graphical 
operating environments. 

The XGA video subsystem program¬ 
ming interface has a complex set of 


hardware registers with selectable 
Input/Output (I/O) and memory- 
mapped addresses. These registers 
and addresses are as follows: 

• 5 Programmable Option Select 
(POS) registers 

• 16 direct I/O registers 

• 128 indirect (indexed) I/O registers 

• 128 memory-mapped graphics 
coprocessor registers 

• 1 MB video buffer memory- 
mapped addresses 

It is impossible to discuss in a single 
article how all these registers are pro¬ 
grammed. This article concentrates 
on the functions within the five POS 
registers used by the XGA Display 
Adapters. 

POS Register Concept 

During Power-On Self Test (POST), 
each adapter’s POS registers are pro¬ 
grammed with information about the 
unique features (the configuration) of 
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Figure 1. Contents of XGA POS Registers 0 and 1: Subsystem Identification 


that adapter. POST reads an adapter’s 
unique POS ID, which is hard-coded 
into the adapter’s POS registers. The 
POS ID code (similar to a product’s 
bar code) identifies the type of adapt¬ 
er resident in a Micro Channel slot. 
During setup, the POST process, in 
conjunction with the system configu¬ 
ration utilities, configures each adapt¬ 
er by programming its POS registers. 

The adapters and the system board 
each have a set of up to eight POS 
I/O addresses between 1 OOh (where 
h denotes hexadecimal) and 107h. 
Depending on the number of unique 
functions incorporated, a specific 
adapter may not need to implement 
all eight POS registers. 

The contents of the POS registers can 
be accessed by using the System Ser¬ 
vices POS BIOS call INT 15 (soft¬ 
ware Interrupt 15) with AH = C4h. 
Although application programs never 
write to the POS registers, they may 
need to read an adapter’s POS regis¬ 
ters. The POS registers can contain 
pertinent information required to run 
an application. 

The XGA POS Registers 

The XGA video subsystem hardware 
interface contains its own distinct 
POS Registers 0, 1,2, 4, and 5, which 
respectively have I/O addresses 
lOOh, 101 h, 102h, 104h, and 105h. 
These registers, which are set up only 
once (during POST), contain informa¬ 
tion about the locations of the XGA 


subsystem registers and the video 
display buffer. 

POS Registers 0 and 1 

XGA POS Registers 0 and 1 contain 
the low and high bytes, respectively, 
of the XGA adapter’s POS ID. The 
currently allocated XGA adapter 
POS ID is 8FDBh. (Additional POS 
IDs, 8FD8 through 8FDA, are 
reserved for future versions of XGA.) 
Figure 1 shows how POS ID 8FDBh 
is situated in POS Registers 0 and 1. 

The system configuration utilities use 
the XGA adapter’s POS ID to locate 
the corresponding XGA Adapter 
Description File (ADF). The ADF 
contains specific information for 
programming the XGA hardware 
registers. Figure 2 shows the ADF 
for the XGA Display Adapter. 

I/O Addressing and 
Memory-Mapped Addressing 

Before describing POS Register 2, it 
is necessary to explain I/O and 
memory-mapped addressing. 

The Intel® microprocessor architecture 
has two distinct modes for addressing 
devices. The first mode is I/O address¬ 
ing. The real-mode DOS environ¬ 
ment has 64 KB of I/O addresses that 
are available for addressing devices 
in the system. In this mode, when the 
processor addresses a device, it uses 
the Intel assembly language IN 
instruction to read the XGA I/O 
registers, and the OUT instruction to 
write to those registers. 


In memory-mapped addressing mode, 
the processor uses Memory Read and 
Memory Write instructions to commu¬ 
nicate with system memory, diskette 
drives, and hard disk drives. Memory- 
mapped addresses total 1 MB in the 
real-mode DOS environment. The 
XGA Display Adapter has memory- 
mapped addresses associated with its 
video RAM and graphics coprocessor. 

POS Register 2 

The primary purpose of XGA POS 
Register 2 is to provide a card-enable 
function. This function permits the 
XGA adapter to be disabled - essen¬ 
tially, turned off - in the Micro Chan¬ 
nel slot, so that it does not respond 
to its assigned I/O addresses and 
memory-mapped addresses. In addi¬ 
tion, POS Register 2 contains the 
XGA adapter’s instance. Because 
there can be up to eight XGA adapters 
present in the system, the instance 
(a number between 0 and 7) distin¬ 
guishes one XGA adapter from 
another. POS Register 2 also houses 
the memory-mapped address range 
selector for the ROM on the XGA 
adapter that contains program code. 
Figure 3 shows the contents of POS 
Register 2. 

ENBL 

In POS Register 2, when the ENBL 
bit (bit 0) is a 1, the XGA video sub¬ 
system is enabled and responds to all 
non-POS addresses (that is, to all 
XGA direct and indirect I/O addresses, 
and to coprocessor and video RAM 
memory-mapped addresses). There 
are 16 direct I/O registers. These 
registers contain indexes to 128 in¬ 
direct registers. Direct and indirect 
registers are discussed at the begin¬ 
ning of this article. When the ENBL 
bit is a 0, the XGA subsystem responds 
only to POS register addresses. 

INST 

The INST field, in bits 1 through 3 
of POS Register 2, defines an XGA 
adapter’s instance. Each XGA instance 
has a unique set of direct and indirect 
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I/O addresses, as well as coprocessor 
and video RAM memory-mapped 
addresses. The instance also is used 
to locate which of the eight blocks of 
128 addresses (refer to Figure 4) is 
assigned to the XGA coprocessor 
registers. 

ROM Address 

The XGA Display Adapter has a 
Read-Only Memory (ROM) contain¬ 
ing the POST code that initializes the 
XGA registers. This ROM occupies 
the first 7 KB of an 8 KB memory 
address block. In POS Register 2, the 
ROM Address field (bits 4 through 7) 
specifies which of 16 possible 8 KB 
blocks of memory-mapped addresses 
has been assigned to this XGA adapter. 

The remaining upper 1 KB of address 
space in this same block is reserved 
for eight instances of the 128 XGA 
coprocessor memory-mapped registers. 

Example 

To use all these concepts, refer to 
Figure 4, which shows the correspon¬ 
dence between the XGA instance and 
the ROM address, and between the 
XGA I/O register and the video ROM 
and coprocessor memory-mapped 
addresses. 

The example in Figure 4 assumes 
that XGA instance 5 (INST=101h) 
and ROM Address 3 (001 lh) have 
been selected. 

In Figure 4, XGA instance 101 h 
yields base address 2150h for the 16 
XGA direct I/O register addresses. 

The 16 registers extend from I/O 
address 2150h through 215Fh. 

At the same time, ROM address 
001 lh provides a ROM memory- 
mapped address range of C6000h to 
C7BFFh. This is the lower 7 KB of 
the 8 KB address block. 

Figure 2. Adapter Description File for the XGA Display Adapter 

Combining XGA instance 101 h and 
ROM Address 001 lh yields a base 
address of C7E80h for the 128 
memory-mapped coprocessor regis- 


Adapterld 08FDBh 

AdapterName “XGA Video Adapter” 

NumBytes 4 

FixedResources 

posl-OXXXXXXOb 
pos3-1100XXXXb exec 

address 32 

Begin Device 03h 02h OOh NoDMA 

Namedltem Prompt "Video I/O Address” 

choice “Instance 6: 2160h - 216Fh” 

pos0=XXXX110Xb io 02160h-0216fh 
choice “Instance 7: 2170h - 217Fh” 

posO-XXXXlllXb io 02170h-0217fh 
choice "Instance 0: 2100h - 210Fh” 

posCHXXXXOOOXb io 02100h-0210fh 
choice “Instance 1: 211Oh - 211Fh” 

posCHXXXXOOIXb io 021lOh-0211fh 
choice “Instance 2: 2120h - 212Fh” 

pos0=XXXX010Xb io 02120h-0212fh 
choice “Instance 3: 2130h - 213Fh” 

pos0=XXXX011Xb io 02130h-0213fh 
choice “Instance 4: 2140h - 214Fh” 

posO-XXXXIOOXb io 02140h-0214fh 
choice “Instance 5: 2150h - 215Fh” 

pos0=XXXX101Xb io 02150h-0215fh 


Help 

“The Video I/O address selects a particular I/O address range for 
the Display Controller Registers. This field also affects the 
exact location of the video coprocessor registers.” 


Namedltem Prompt “Video Arbitration 
choice "Arbitration level 13* 
choice "Arbitration level 12* 
choice “Arbitration level 11* 
choice "Arbitration level 10’ 
choice “Arbitration level 9* 
choice "Arbitration level 8’ 
choice “Arbitration level 14’ 


Level” 

posl-XllOIXXXb arb Odh 
posl=X1100XXXb arb Och 
posl-XIOllXXXb arb Obh 
posl-XIOlOXXXb arb Oah 
posl-XIOOIXXXb arb 9 
posl-XIOOOXXXb arb 8 
posl-XlllOXXXb arb Oeh 


Hel p 

“The video subsystem can be assigned any one of the 
available arbitration levels 8 through 14. Use the 
F5-Previous and the F6=Next keys to change arbitration 
level assignments if you are in the 'Change Configuration’ 
window. Conflicting assignments are marked with an asterisk 
and should be changed.” 

Namedltem Prompt “Video Fairness” 

choice "Fairness On” posl-XXXXXlXXb 
choice “Fairness Off” posl-XXXXXOXXb 

Help 

“Video Fairness indicates whether or not the video 
subsystem coprocessor will follow the fairness algorithm 
for bus usage. This setting can be changed if you are in 
the 'Change Configuration’ window by using the 
F5~Previous and F6=Next keys.” 

End 
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Figure 3. Contents of XGA POS Register 2: ENBL Bit, Instance, and ROM Address 


ters. These registers reside within 
the upper 1 KB of the same 8 KB 
address block, and they extend from 
address C7E80h through C7EFFh. 

POS Register 4 

POS Register 4, shown in Figure 5, 
contains the base address of XGA 
video memory. 


Video Memory Base Address 

The XGA Display Adapter contains 
up to 1 MB of video memory. The 
seven most significant bits of the 
base address of the XGA memory are 
defined in bits 1 through 7 of POS 
Register 4. The three least significant 
bits of the base address of XGA mem¬ 
ory are defined in the three XGA 


instance bits in POS Register 2. These 
two fields of bits are concatenated to 
define a 10-bit video memory address 
located on a 4 MB address boundary. 

Figure 6 shows how to determine the 
video memory address. In Figure 6, 
bits 25 through 31 contain a copy of 
the information in bits 1 through 7 of 
POS Register 4. These seven most 
significant bits of the video memory 
address are set to binary 4 (0000100b). 
Also in Figure 6, bits 22 through 24 
contain a copy of the information in 
the XGA instance (bits 1 through 3 
of POS Register 2). These three least 
significant bits of the video memory 
address are set to binary 3 (01 lb). 


ROM Address 
0011 


ROM Address Range 
C6000 - C7BFF 


Coprocessor Base Address C7E80 (Addresses C7E80 - C7EFF) 


ROM Address / 


Coprocessor Register Base Address (in Hex) 

Instance (INST) 


Field 

Range (in Hex) 

0 

1 

2 

3 

\ 4 

1-1 

lAI 

6 

7 

0000 

C0000-G1BFF 

Cl COO 

C1C80 

C1D00 

C1D80 

cYeoo 

C1E80 

C1F00 

C1F80 

\ 0001 

C2000-C3BFF 

C3C00 

C3C80 

C3D00 

C3D80 

C3E00 

C3E80 

C3F00 

C3F80 

\ooio 

C4000 -]C5BFF 

C5C00 

C5C80 

C5D00 

C5D80 

C5E00 X 

^ C5E80 

C5F00 

C5F80 

[oojTj 

j~C6000 - C7BFF~] 

C7C00 

C7C80 

C7D00 

C7D80 

C7E00 

[C7_E80J 

C7F00 

C7F80 

0100 

C8000 - C9BFF 

C9C00 

C9C80 

C9D00 

C9D80 

C9E00 

C9E80 

C9F00 

C9F80 

0101 

CA000 - CBBFF 

CBCOO 

CBC80 

CBDOO 

CBD80 

CBEOO 

CBE80 

CBFOO 

CBF80 

0110 

CC000 - CDBFF 

CDCOO 

CDC80 

CDDOO 

CDD80 

CDEOO 

CDE80 

CDFOO 

CDF80 

0111 

CE000 - CFBFF 

CFCOO 

CFC80 

CFDOO 

CFD80 

CFEOO 

CFE80 

CFFOO 

CFF80 

1000 

D0000- D1BFF 

D1C00 

D1C80 

D1D00 

D1D80 

D1E00 

D1E80 

D1F00 

D1F80 

1001 

D2000 - D3BFF 

D3C00 

D3C80 

D3D00 

D3D80 

D3E00 

D3E80 

D3F00 

D3F80 

1010 

D4000 - D5BFF 

D5C00 

D5C80 

D5D00 

D5D80 

D5E00 

D5E80 

D5F00 

D5F80 

1011 

D6000 - D7BFF 

D7C00 

D7C80 

D7D00 

D7D80 

D7E00 

D7E80 

D7F00 

D7F80 

1100 

D8000 - D9BFF 

D9C00 

D9C80 

D9D00 

D9D80 

D9E00 

D9E80 

D9F00 

D9F80 

1101 

DA000 - DBBFF 

DBCOO 

DBC80 

DBDOO 

DBD80 

DBEOO 

DBE80 

DBFOO 

DBF80 

1110 

DC000 - DDBFF 

DDCOO 

DDC80 

DDDOO 

DDD80 

DDEOO 

DDE80 

DDFOO 

DDF80 

mi 

DE000 - DFBFF 

DFCOO 

DFC80 

DFDOO 

DFD80 

DFEOO 

DFE80 

DFFOO 

DFF80 

XGA "INST" Field 

000 

001 

010 

Oil 

100 

AAPA 

110 

111 

I/O Base Address 

2100 

2110 

2120 

2130 

21^Q / 

[ 2150 ] 

2160 

2170 


Instance 5 


I/O Base Address 2150 
Addresses 2150-215F 


Figure 4. XGA 1/0 Address and Memory-Mapped Address Blocks 
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Figure 5. Contents of POS Register 4: Video Memory Base Address 
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Figure 6. Finding the Base Address of XGA Video Memory 
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- 
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API - 1 MB aperture 


Video Memory Aperture 
00500000 - 005FFFFFh 


API = 5 


\ API 

1 MB Aperture / 

\ 0000 

Disabled 

\ 0001 

00100000 1 

\ 0010 

00200000 

\ 0011 

00300000 

loioo 

00400000 i 

1 - 1 

r ~i 

LOiojj 

|00500000| 

0110 

00600000 

0111 

00700000 

1000 

00800000 

1001 

00900000 

1010 

00A00000 

1011 

00B00000 

1100 

oocooooo 

1101 

00D00000 

1110 

00E00000 

mi 

00F00000 


Figure 7. Contents of XGA POS Register 5:1 MB Aperture 


Figure 8. Video Memory 1 MB Aperture 
Base Address 


Together, bits 22 through 31 in Fig¬ 
ure 6 constitute the 10-bit video mem¬ 
ory address. Next, bits 0 through 21 
in Figure 6 contain zeros. These rep¬ 
resent the 4 MB address boundary. 
Finally, bits 0 through 31, taken 
together as one big number, yield the 
video memory address of 08C00000h. 
This is a 32-bit address that can be 
handled only by 32-bit 80386 and 
80486 processors (see the article “Mem¬ 
ory Address Space” in this issue). 

Video Enable (VE) 

There is a 4 MB aperture through 
which XGA video memory can be 
accessed. The aperture is a range of 
system addresses through which an 
application program can write to, or 
read from, the video memory. When 
the Video Enable (VE) bit in POS 
Register 4 is set to 1, the 4 MB 
address aperture is enabled; when the 


VE bit is 0, the 4 MB aperture is 
disabled. 

POS Register 5 

The XGA Display Adapter also has a 
1 MB aperture (not the same as the 4 
MB aperture just mentioned) through 
which the video memory also can be 
accessed. As shown in Figure 7, bits 
0 through 3 of XGA POS Register 5 
define where the 1 MB aperture is 
located in the system address space. 

Figure 8 shows the correspondence 
between the contents of the four-bit 
field labeled API in Figure 7 and the 
address of the 1 MB aperture. In Fig¬ 
ure 8, when the four bits in API are 
set to 5 (0101 b), the video buffer can 
be accessed through the 1 MB aper¬ 
ture located between addresses 
00500000h and 005FFFFFh. 


Jim Paolantonio is an advisory 
engineer in visual subsystems 
within the IBM Entry Systems 
Technology laboratory in Boca 
Raton, Florida. His current 
responsibilities include Very 
Large-Scale Integration (VLSI) 
Liquid-Crystal Display (LCD) 
controller-chip development for 
portable systems. Jim's previous 
assignment was XGA video hard¬ 
ware development for the IBM 
PS/2 Model 90 XP 486. He has 
also been a member of develop¬ 
ment engineering teams for the 
IBM PS/2 Model 80, PC AT®, and 
PC/XT™. Jim holds BS and MS 
degrees in electrical engineering 
from Purdue University. 
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Video Monitoring on 
Personal Computers 

Geoffrey R. Amthor 
Impact Ideas, Inc. 

Flowery Branch, Georgia 

With the IBM video monitoring solution, the gap between digital com¬ 
puters and analog video has been bridged. Now the two great information 
revolutions of the 20th centuty - computing and television - can be 
brought together seamlessly at the desktop with single-cable network- 
ability across entire organizations and at a surprisingly affordable price. 


I n most organizations today, desktop 
video means walking to a confer¬ 
ence room and playing a video¬ 
tape. While you are viewing that 
tape, you are out of touch with your 
colleagues, perhaps missing spur-of- 
the-moment meetings and important 
phone calls. 


The same situation is true for live 
video. If you are a financial broker, 
you want to keep in touch with world 
events or current market activity. If 
you are an employee in a large cor¬ 
poration, you want to keep abreast of 
events aired on the internal TV net¬ 
work. In both cases, you face a choice 


of having a TV on your desk or shut¬ 
tling to a conference room to view 
broadcasts. 

IBM Video Monitoring 
Solution 

With the IBM video monitoring solu¬ 
tion, you can have TV in your desk¬ 
top computer. Everyone who needs 
video sources, such as cable TV, broad¬ 
cast TV, VCRs, videodisc players, 
internal corporate TV, and closed- 
circuit TV, can do so conveniently at 
a desktop computer - whether the com¬ 
puter is a PS/2, PC AT, or compatible. 

These video sources can be displayed 
in full-screen mode or in a window 
alongside computer applications on 
standard VGA monitors. IBM’s 
video monitoring solution supports 
video distribution over token-ring 
Local Area Networks (LANs) that 
use the IBM Cabling System (ICS). 
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Video is one of many applications 
run at the desktop - with no impact 
on the performance of digital appli¬ 
cations. Because the technology is 
affordably priced, video monitoring 
can be deployed across entire organ¬ 
izations. In token-ring installations, 
more than 70 channels of video can 
be passed simultaneously over the 
network. 

PS/2 TV 

The key enabling product of IBM’s 
video monitoring solution is IBM 
PS/2 TV, shown in Figure 1. It is 
packaged in the slim external enclo¬ 
sure positioned directly beneath the 
PS/2 monitor in the figure. It con¬ 
tains a 181-channel, cable-ready TV 
tuner that accepts National Television 
Standards Committee (NTSC) broad¬ 
cast signals from a cable TV source 
or antenna, as well as standard base¬ 
band video input from a VCR, laser 
videodisc player, or video camera. 

An internal speaker, headphone jack, 
and a set of video and audio input/ 
output connectors complete the PS/2 
TV unit. PS/2 TV is a very affordable 
enhancement to desktop PS/2, PC 
AT, and compatible systems 1 . 

During installation, the PS/2 display 
cable is routed from the monitor to 
the PS/2 TV unit, with a second video 
cable going from the PS/2 TV unit to 
the PS/2 system unit. Similarly, the 
keyboard cable is routed directly to 
the PS/2 TV unit, with a second key¬ 
board cable routed from the PS/2 TV 
unit to the standard keyboard connec¬ 
tor in the PS/2 system unit. When the 
PS/2 TV unit is inactive, keyboard 
and video signals pass through the 
unit unimpeded. 

PS/2 TV is activated through either 
software or a hot-key combination 
captured by the unit. When activated, 
PS/2 TV has standard television con¬ 
trols - channel selection, volume, 



Figure 1. PS/2 TV 



Figure 2. IBM F-Coupler with Faceplate 


mute, brightness, contrast, and color. 
It provides three viewing modes: 

• The normal full-screen computer 
display 

• Full-screen television 

• A full-screen user application over¬ 
laid with a movable Picture-in- 


Picture (PIP) TV video image, 
which uses one-ninth of the screen 
(In its current version, PS/2 TV 
supports PIP functions only in 
VGA display mode; XGA is sup¬ 
ported only in full-screen mode.) 

Audio is available in any of the modes, 
and it can be muted. Video received 


1 This article refers to a desktop computer as a PS/2. However, IBM PS/2 TV supports the VGA-enabled IBM PC AT and fully compatible desktop 
computers. A PC AT and some compatible computers require a keyboard port adapter that is supplied with IBM PS/2 TV. 
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can be recorded onto a VCR by using 
PS/2 TV’s video- and audio-out capa¬ 
bilities. The keyboard is normally 
used to control PS/2 TV, but under 
OS/2 or Windows the functions can 
be controlled through menu selec¬ 
tions as a concurrent application. 

Display modes can be changed and 
television parameters controlled just 
as with a standard television set. Con¬ 
trol is fast and intuitive - a novice 
can learn in minutes. 

Because PS/2 TV comes with its own 
microcontroller, video places no 
demands on the PS/2 system unit. 
Computer applications run as fast as 
ever. 

IBM PS/2 TV offers an affordable 
enhancement to desktop PS/2s. At 
the time this article was written, the 
suggested retail price in the U.S. was 
$495 2 . 

Network Distribution System 

While PS/2 TV is often used in stand¬ 
alone implementations, it also can be 
used as part of an organization-wide 
strategy of accessing networked 
video from desktops. 

A basic distribution system can be 
installed simply by wiring standard 
coaxial cabling to each PS/2 TV unit 
in the organization. At the studio 
headend, several video sources can 
be distributed on their own program¬ 
ming channel; video source choices 
include cable TV, satellite, antenna, 
VCRs, videodisc players, and video 
cameras. In addition to the video 
sources, a distribution system is 
required, typically consisting of a 
combiner, an RF video distribution 
amplifier, and a multisplitter. 

For organizations with existing or 
planned token-ring networks using 
the shielded twisted-pair IBM Cabling 


System, a novel approach can take 
advantage of the ICS cabling and 
eliminate the need to pull separate 
coaxial cabling for video signals. 

This exciting solution is possible be¬ 
cause both 4 Mbits and 16 Mbits per 
second token-ring networks leave 
approximately 500 MHz of free 
bandwidth, which is available for 
video transmissions. In turn, this free 
bandwidth can easily support over 70 
channels of video. 

F-Coupler 

To distribute video over a token-ring 
network, a filtering device called an 
IBM F-Coupler must be added at 
each endpoint, as shown in Figure 2. 
One F-Coupler at the headend mer¬ 
ges data signals from the token-ring 
Multistation Access Unit (MAU) 
with video, as shown in Figure 3. 

The F-Couplers at the PS/2 endpoints 
separate those signals. In small instal¬ 
lations, the headend F-Coupler may 
be located in a studio with the video 
sources, the video distribution system 
(combiner, RF video distribution 
amplifier, and splitter), and the token¬ 
ring MAU. In larger installations, the 
headend F-Coupler would be placed 
on the token-ring distribution panel 
in the wiring closet where video and 
data signals are received. 

Because wiring represents a signifi¬ 
cant expense in a cabling system, the 
IBM F-Coupler affords an excellent 
way to reduce the investment re¬ 
quired to handle data and video trans¬ 
missions that previously have used 
separate cables. 

The IBM F-Coupler is a highly 
affordable distribution solution. At 
the time this article was written, 
F-Couplers had a suggested retail 
price in the U.S. of $85 each. Each 
receiving F-Coupler needs a special 
faceplate (shown in Figure 2). At this 


writing, faceplates were available for 
a suggested retail price of $6.85. 

Video Monitoring Applications 

IBM PS/2 TV enables video feeds 
from sources such as cable TV, 

VCRs, videodisc players, and closed- 
circuit cameras to be displayed on 
existing PS/2 monitors - eliminating 
the need for redundant equipment 
and allowing video to be integrated 
into normal working environments. 
Combining both pieces of equipment 
saves desk space and cost. More im¬ 
portant, time is saved because users 
can quickly switch between video 
and computer information. 

Now you can access a world of video 
sources. Imagine the applications! 

Broadcast monitoring: Information 
sources such as network and cable 
news broadcasts can be monitored on 
a workstation. This function is valu¬ 
able to stockbrokers, financial ana¬ 
lysts, journalists, and others who 
need to keep abreast of world events. 
A small window displays the live 
video feed while they continue to per¬ 
form their normal work routines. To 
enhance concentration on normal 
work, video can be delivered silently, 
or the program can be monitored in 
audio-only mode. When an item of 
interest arises in the broadcast, the 
user can jump into PS/2 TV’s dedi¬ 
cated mode, complete with full¬ 
screen video and audio. The result is 
easy access to vital information and 
improved productivity. 

Business television: Many corpora¬ 
tions today have private video studios 
that produce internal programming 
comparable to that of major televi¬ 
sion networks. Satellite and mobile 
uplink facilities are readily available 
and reasonably priced. With the IBM 
video monitoring solution, even 
small companies can broadcast inter- 


2 Prices are subject to change. For a limited time, the IBM Multimedia Information Center is offering PS/2 TV direct for $399. Call (800) 426-9402. 
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nal programming to the desktops of 
their workers - allowing them to 
work at their desk and still receive 
vital corporate broadcasts convenient¬ 
ly. Another excellent application is 
business-to-business television. IBM 
customers can use the video monitor¬ 
ing solution to view IBM Field Tele¬ 
vision Network (FTN) telecasts in 
their own offices. 


Training: The cost of training 
employees goes far beyond curricu¬ 
lum materials and trainer fees. For 
live training, organizations also must 
consider travel and housing expenses 
and the loss of employee time from 
their day-to-day positions. For 
“canned’’ training delivered by video¬ 
tape, students usually leave their 
desks and go to a conference room or 


training facility. With the IBM video 
monitoring solution, that material can 
be delivered directly to student desk¬ 
tops. For live training, students can 
still interact with the instructor by 
telephone - allowing cost-effective 
training anywhere. Taped instruction 
also can be played from a VCR 
attached directly to the PS/2 TV at 
the desktop. 
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Video library: While organizations 
often store large volumes of video¬ 
tapes and videodiscs, the process of 
getting a video to a requester can be 
time-consuming and costly. The IBM 
video monitoring solution enables 
the creation of a centralized video 
library where tapes are loaded for 
local viewing at desktops. Equipment 
also is available to further automate 
the operation of video libraries by 
providing remote control or auto¬ 
mated operations. A hybrid digital/ 
analog video solution also can be 
created, where video is stored digital¬ 
ly on network servers and converted 
for analog transmission to the desk¬ 
top. This analog transmission avoids 
clogging network bandwidth with 
digital video, while it preserves the 
flexibility of digital video editing and 
storage. 

Manufacturing and process 
monitoring: Manufacturing super¬ 
visors can now work on their desktop 
computer applications while keeping 
an eye on the manufacturing line - 
thanks to IBM PS/2 TV and closed- 
circuit television. Intelligent video 
workstations can be programmed to 
monitor critical safety issues and 
alert an operator when needed. 

Store monitoring: Sales clerks can 
ring up transactions on PS/2 systems 
while keeping an eye on store opera¬ 
tions - thanks again to the pairing of 
IBM PS/2 TV and closed-circuit 
cameras. 

Surveillance monitoring: Multiple 
PS/2 TV units can be attached to a 
single PS/2, allowing several surveil¬ 
lance cameras to display within win¬ 
dows on a single monitor. Motion 
detectors and other system peripher¬ 
als, such as autodialers, can transform 
a desktop PS/2 into a comprehensive 
security system. 

Videoconferencing: The same infra¬ 
structure and equipment used for one¬ 


way video can enable two-way video 
within a building. By splitting the band 
of video frequencies into forward and 
reverse channels, a technician can 
design the distribution system to 
allow point-to-point video and voice 
communication. If the facility has a 
videoconferencing suite that uses a 
codec for land-line wide-area video- 
conferencing, it can be extended to 
allow an executive to join a confer¬ 
ence being conducted on another 
floor of the building. 



With the IBM video 
monitoring solution, 
organizations can 
broadcast live from the 
executive offices to 
workers watching at 
their desks. 


Group meetings: Employee meet¬ 
ings frequently involve large groups 
of people crowded into a conference 
room, viewing a videotaped message 
from management. With the IBM 
video monitoring solution, organiza¬ 
tions can broadcast live from the exec¬ 
utive offices to workers watching at 
their desks. Employees can interact 
by telephone or video conference 
link. For those who missed the meet¬ 
ing, a tape can be played for several 
days from a library. Employees need 
only select the appropriate channel 
on their workstations. 

Collaborative workstations: Multi- 
media applications and presentations 
are often created by a team of work¬ 
ers who concentrate on specific parts 
of the overall project. Presentation 
files can be created and stored on a 
token-ring network file server, while 
video segments can be stored in ana¬ 


log form on a central VCR or laser¬ 
disc player/recorder. When the team 
is supported by the video monitoring 
solution, all team members can 
remotely access both analog and digi¬ 
tal sources conveniently from their 
desks. 

Schools: Schools may discover that 
video information is more effective 
when delivered to the students’ 
desks. Instead of displaying video on 
a large-screen television to a class¬ 
room of students, schools can deliver 
important documentaries and educa¬ 
tional videos to classroom PS/2s 
equipped with PS/2 TV. 

Home: With a stand-alone PS/2 TV 
unit, home office and weekend 
workers do not have to choose be¬ 
tween computer-based work and 
catching the weekend ball game. 

They can do both, right on their 
home PS/2 systems. 

Installing and Using PS/2 TV 

Setting up a local PS/2 TV unit is a 
matter of connecting a few cables, 
selecting a video source, and making 
a couple of adjustments. Because 
PS/2 TV is an external device, it is 
not necessary to open the PS/2 sys¬ 
tem unit for installation. Instead, the 
installation process is analogous to 
installing a home VCR between 
video inputs and the TV monitor. 

Several cables pass through the PS/2 
TV unit: 

• The keyboard plugs into the IBM 
PS/2 TV unit, with an output cable 
connected to the PS/2 system. 

• The display cable is routed from 
the monitor to the IBM PS/2 TV 
unit, with a cable then connected 
to the IBM PS/2 system unit. 

• The video source - VCR, video¬ 
disc player, antenna, cable TV, or 
closed-circuit camera - is hooked 
up directly to the IBM PS/2 TV unit. 
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Figure 4. Additional Bandwidth Available with Shielded Twisted Pair 


• A power cable runs from a wall 
transformer to the IBM PS/2 TV 
unit. 

• There are video- and audio-out 
connectors in the IBM PS/2 TV 
unit for the attachment of a VCR 
or other recording device. 

How PS/2 TV Works 

Once cabled and configured, the 
IBM PS/2 TV unit is always ready. 

As with any television set, the picture 
and sound are standing by - waiting 
for the user to turn on the set, select a 
channel, and adjust the volume. With 
PS/2 TV, you make a few other deci¬ 
sions too, such as selecting a viewing 
size, placement of the video window, 
and any personal fine tuning. In all 
cases, PS/2 TV’s display overlays the 
VGA signals from the PS/2 system 
unit, much like a VCR’s on-screen 
programming instructions overlay the 
TV’s own video display. 

The PS/2 TV unit picks up the video 
signal from a designated source: 
antenna, cable, VCR, or videodisc. 

On user command, it then delivers 
this video to the PS/2 display. There 
are three display options: 

• Full-screen computer application 
display (PC mode) 

• Picture-in-Picture video window, 
overlaying the active computer 
application 

• Full-screen video display 

You can quickly switch among these 
modes by pressing a key or clicking a 
mouse. 

How to Control PS/2 TV 

The method of turning on the “set,” 
choosing a channel, or making adjust¬ 
ments depends on the operating sys¬ 
tem. With DOS, a series of keyboard 
entries is used for volume, channel 
selection, picture adjustments, view¬ 
ing mode, and picture location. As 
each decision is made, a correspond¬ 


ing on-screen panel highlights and 
guides interactions. You also can 
select a timeout for these panels. 

When the keyboard is used for these 
adjustments and actions, it is tempo¬ 
rarily dedicated to the PS/2 TV unit. 
Pressing the Num Lock key twice in 
quick succession activates this dedi¬ 
cated mode. When you are finished, 
the Escape key returns control to the 
PS/2 system unit. No software is re¬ 
quired for this keyboard operation. 

In a Windows or OS/2 environment, 
there is an option of using these same 
key sequences or a series of menus 
and control panels to perform all the 
PS/2 TV functions. Windows and 
OS/2 application software are 
provided with the PS/2 TV. 

Customizing PS/2 TV 

A supplemental Application Program¬ 
ming Interface (API) is included with 
PS/2 TV for organizations that need 
the capabilities of the PS/2 TV in a 
program-controlled interactive envi¬ 
ronment. The PS/2 TV User s Guide 
documents the API, describes how to 
code to it, and gives examples. 

An organization may want to store 
video segments as objects in a 
remote videodisc library. By writing 
a custom program to the optional 
API, organizations can provide users 
with automated access to these seg¬ 


ments from desktops. You can simply 
select a video segment from a menu; 
in turn, the customized environment 
would direct the video distribution 
system to search for an open video 
channel. After selecting an open 
channel, the customized environment 
would then tune the PS/2 TV unit to 
the chosen channel and begin video 
transmission. 

An automated system also could be 
used to play Digital Video Interactive- 
(DVI-) compressed digital video 
stored on remote CD-ROM or hard 
disk servers, with “on the fly” 
conversion to analog signals for 
transmission. 

How F-Coupler Works 

With the IBM F-Coupler, an organi¬ 
zation can now assemble a complete 
network for all its video, audio, and 
data needs using a single installation 
of a shielded twisted-pair IBM 
Cabling System. 

Operating in a 4 Mbits or 16 Mbits 
per second token-ring environment, 
approximately 500 MHz of free band¬ 
width is available for video transmis¬ 
sions in the 50 MHz to 550 MHz 
range. This free bandwidth, shown 
conceptually in Figure 4, can easily 
support over 70 channels. 

Frequency Division Multiplexing 
(FDM) techniques make this greater 
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cable bandwidth utilization possible. 
Specifically, the ICS uses high- 
quality cable that can support signal 
transmissions at the high frequencies 
used for broadband audio and video, 
as well as the data transmissions for 
which it has been used historically. 
This shielded, twisted-pair cable con¬ 
tains both aluminum foil and mesh 
shield, enabling it to handle the 
simultaneous transmission of broad¬ 
band and baseband signals. 

With an IBM F-Coupler on each end 
of the cable, a higher frequency sig¬ 
nal for audio and video is transmitted 
on top of the data signal. The head- 
end F-Coupler combines the two sig¬ 
nals into a single transmission, while 
the receiving F-Coupler separates the 
signals and routes them to their 
appropriate ports. Each F-Coupler 
includes both a coaxial connector for 
broadband signals and a data connec¬ 
tor for baseband signals. A circuit in 
the F-Coupler is designed to isolate 
the different signals from each other 
on their respective bandwidths, main¬ 
taining complete isolation during 
transmission. 

Flexibility of Use 

The ICS/broadband LAN can be 
adapted into a variety of configura¬ 
tions, depending upon the unique 
needs of each user. 

Video signals can originate from an 
antenna, VCR, or video camera. These 
broadband signals are then transmitted 
on coaxial cable to a multi-splitter 
(or tap/combiner) that leads to the 
CATV distribution panel in the wir¬ 
ing closet. It is here that the video 
signals are directed to the F-Coupler. 
Simultaneously, data signals also are 
transmitted on the IBM Token-Ring 


network to the wiring closet, where 
they too are routed to the F-Coupler. 

Leaving the wiring closet, shielded 
twisted-pair wiring on the ICS carries 
both baseband and broadband signals 
to the end of the cable drop. At that 
point, the F-Coupler at the faceplate 
separates the signals, sending the 
data to the PS/2 workstation while 
the broadband transmission is 
directed to a video receiver. 



Once cabled and 
configured, the 
IBM PS/2 TV unit 
is always ready. 


Easy Installation 

To install this system, a technician 
places one F-Coupler on the ICS dis¬ 
tribution panel in the wiring closet 
where the video and data signals are 
received. Another F-Coupler is 
placed in the office or conference 
room where the signals are to be 
separated. A special faceplate is re¬ 
quired to enable both coaxial cable 
connection of the video and a token¬ 
ring attachment. 

Technicians installing the devices 
must consider the total length of 
cable in the network, as well as the 
length of cable in each node in the 
network. Recommended cable 
lengths can be obtained from the 
F-Coupler Planning Guide (GA27- 
3949) or other documentation such as 
the IBM Cable System Planning and 
Installation Guide (GA27-3361). 


Similarly, installation of an ICS 
broadband LAN requires calculating 
the attenuation of the video signal as 
a function of both signal frequency 
and cable length. This information is 
available from the F-Coupler 
Planning Guide. 

References 
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tion Instructions (GA27-3950) 

• PS/2 TV User’s Guide 
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Memory Address Space 

Rick Dayan 
IBM Corporation 
Boca Raton, Florida 

This article discusses memory address space in several generations of 
microprocessors and how memoiy has been allocated in those processors. 
The concepts of system memory , nonsystem memory , and memory regions 
are introduced. 


E veryone is familiar with the 
famous 640 KB boundary for 
memory available for DOS 
applications. There is a similar situa¬ 
tion in 80386 SX-based systems today. 
These systems can be populated with 
up to 16 MB of physical memory; 
however, only 15 MB of that mem¬ 
ory can be accessed for system use. 
Although the 640 KB boundary and 
the 15 MB upper limit occur in com¬ 
puters that are several generations 
apart, the two situations are basically 
the same. 

Why is it impossible to access some 
physical memory? What happens to 
that memory? How is it used? By 
answering these questions, this article 
can help users plan how much physi¬ 
cal memory, and what kinds of mem¬ 
ory, to add to their 80386 SX-based 
systems. 

What is Memory 
Address Space? 

Every processor has memory address 
space , which is defined by the num¬ 
ber of address pins on the processor 
chip plus one additional pin. The 
additional pin designates that the 
address bus contains a valid memory 
address. 

A car analogy easily explains the dif¬ 
ference between physical memory 
and memory address space. Suppose 
the seating capacity of the car is four. 
A four-seat car will work with just a 


driver. It is still called a four-seater, 
regardless of whether it is fully occu¬ 
pied. You would not say that the car 
is a one-seater because only one seat 
is occupied. 

The car’s seating capacity is analo¬ 
gous to the computer processor’s 
memory address space, and the car’s 
driver is analogous to physical mem¬ 
ory. By putting 2 MB of physical 
memory into a computer that has 
16 MB of memory address space, the 
address space is still 16 MB, though 
only 2 MB are physically occupied. 

Processors behave as though the 
entire memory address space always 
exists, whether or not the space is 
actually populated with memory. The 
user must decide whether to populate 
the memory address space with 
memory. 

System and Nonsystem 
Memory 

Returning to the car analogy, suppose 
that the driver of the four-seat car 
goes grocery shopping. The groceries 
are placed in the two rear seats. Al¬ 
though the rear seats were intended 
for use by people, they can certainly 
be occupied by groceries. With the 
groceries there, the two rear seats are 
now unavailable for people to use. 

In computers, memory address space 
is intended for use by system mem¬ 
ory, but the space also can be popu¬ 


lated by nonsystem memory. The 
nonsystem memory occupies mem¬ 
ory address space that is ordinarily 
used for system memory. 

What is the difference between sys¬ 
tem memory and nonsystem mem¬ 
ory? System memory - which is 
owned, managed, and allocated by 
the operating system - is for general 
storage of operating system code, 
application code, and data. Nonsys¬ 
tem memoiy is not owned by the 
operating system; it has a dedicated 
purpose - typically used by feature 
adapters to provide programming 
interfaces, device control, and data 
buffers. 

Memory address space can contain a 
mixture of several different memory 
technologies: Read-Only Memory 
(ROM), Random Access Memory 
(RAM), flash memory. Erasable Pro¬ 
grammable Read-Only Memory 
(EPROM), and so on. Only RAM 
can be system memory. Nonsystem 
memory consists of memory other 
than RAM, as well as RAM memory 
that is dedicated to interfacing with a 
feature adapter. 

In the car analogy, suppose that on 
the way home with the groceries, the 
driver spots two friends who need a 
ride. The driver stops to pick up the 
friends, but then realizes that there is 
only one unoccupied seat. The driver 
tells one friend to get in the car and 
tells the other to wait for another ride. 

The computer similarity is this: Sup¬ 
pose that a computer system has 16 
MB of memory address space, and 
that nonsystem memory occupies 2 
MB of that space. The user has sys¬ 
tem memory modules that could fully 
populate the 16 MB space with system 
memory. However, the user finds it is 
impossible to add and access all the 
available system memory modules, 
because 2 MB of memory address 
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Figure 1. 1 MB Memory Address Space of the 8088 Processor 


space are already occupied by non¬ 
system memory. 

During configuration of the memory 
address space, allocation of nonsys¬ 
tem memory takes precedence over 
allocation of system memory. Non¬ 
system memory must take precedence 
because if a feature adapter requires 
memory as its interface to the sys¬ 
tem, then nonsystem memory is the 
only way to add feature-adapter 
functions to the system. 

Allocations of nonsystem memory 
are not readily apparent to users. The 
existence of nonsystem memory 
becomes apparent only after system 
configuration, and only if the nonsys¬ 
tem memory replaces system mem¬ 
ory or if the user views the system 
configuration using Setup. 

Address Lines 

The total size of the memory address 
space depends on the number of 
address lines (also known as address 
pins or address signals) coming from 
the processor chip. 

• The 8086 and 8088 processors 
have 20 address lines that support 
a 1 MB memory address space. 


These processors can access 
addresses between 0 and FFFFFh 
(where “h” denotes hexadecimal). 
FFFFFh is the address 1 MB 
minus 1. 

• The 80286 and 80386 SX proces¬ 
sors have 24 address lines that sup¬ 
port a 16 MB memory address 
space (from 0 to FFFFFFh). 

• The 80386 DX, 80486 SX, and 
80486 DX processors have 32 
address lines that support a 4 GB 
memory address space (from 0 to 
FFFFFFFFh). 

This article discusses only the 8088, 
80286, and 80386 DX processors. To 
apply the information in this article 
to other processors, refer to the proc¬ 
essor relationships in the three bullets 
above. 

From a programmer’s viewpoint, 
there is a direct correlation between 
the number of address lines coming 
from the processor and the number 
of address bits used by programs to 
access data. For example, the 8088 
processor has 20 lines of address; 
therefore, to access data with the 
8088, the programmer uses a seg¬ 
ment register plus an offset register. 


The processor converts the contents 
of those registers to 20 address bits. 

The use of memory address space has 
evolved with new generations of 
processors. 

8088 Memory Address Space 

The IBM Personal Computer and Per¬ 
sonal Computer XT™ have a 1 MB 
memory address space in the 8088 
processor, with 384 KB allocated as 
follows: 

• 40 KB for I/O routines that mask 
I/O device idiosyncracies from the 
operating system and application 
software; contains Basic Input/Out¬ 
put System (BIOS) routines - the 
initialization vector (the first in¬ 
struction fetched by the processor 
at power-on or reset). Cassette 
BASIC, and Power-On Self Test 
(POST) 

• 128 KB for the video buffer 

• 216 KB for expansion memory 

Figure 1 shows the memory map 
detailing this information. Memory 
Region 1 represents the memory 
address space of the 8088 processor. 
Region 1, which ranges from address 
0 to address 1 MB minus 1, also is 
called the real mode of the processor. 

These dedicated functions in nonsys¬ 
tem memory are placed into the upper¬ 
most 384 KB of the 1 MB address 
space. Because it contains nonsystem 
memory, this area is not available to 
the operating system and applications 
for program and data storage. The 
lower boundary of this area is at 640 
KB, or AOOOOh. The memory address 
space below 640 KB is for operating 
system code, application code, data, 
and input/output buffers. This is the 
origin of the 640 KB maximum for 
DOS programs. The 384 KB block of 
nonsystem memory became an impor¬ 
tant factor when memory increments 
increased in size and exceeded 640 
KB. 
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Memory increments for the 8088 
processor are either 16 KB or 64 KB. 
Those small increments meant that 
users could purchase the exact 
amounts of memory they needed, and 
the memory increments could fill any 
unoccupied gaps in the address space 
between the top of system memory 
and the 640 KB boundary. Therefore, 
all memory added to an 8088 system 
is utilized; there is no “extra” memory 
that cannot be used. (This contrasts 
with the situation in later generations 
of systems where minimum memory 
increments are 1 MB, and not all of 
that memory can be used by the 
system.) 

The 640 KB boundary was not a 
problem in the early 1980s. Applica¬ 
tions did not require much space and 
only one program resided in memory 
at a time. However, as users began to 
require more function and to run mul¬ 
tiple programs simultaneously, the 
640 KB boundary became a barrier. 

The IBM PC/XT introduced the 
feature-adapter expansion area that 
allowed feature adapters to obtain 
nonsystem memory allocations. The 
adapter expansion area was located 
above the 640 KB boundary at 
COOOOh, so it made use of that pre¬ 
viously reserved area. The adapter 
area did not affect the memory al¬ 
ready assigned to operating system 
and application storage. 

80286 and 80386 SX 
Memory Address Space 

The next processor was the 80286 in 
the IBM Personal Computer AT®. 
From a memory address space per¬ 
spective, the 80386 SX processor is 
identical to the 80286. 

The 80286 processor increased the 
available memory address space 
from 1 MB to 16 MB. The 80286 had 
both the original real mode (Memory 
Region 1) and a new mode called 
protected mode. The 80286 had to 
run in protected mode to address the 


region from 1 MB to 16 MB, which 
is Memory Region 2. Real mode 
(Memory Region 1) is the memory 
address space from 0 to 1 MB minus 
1; protected mode in the 80286 proc¬ 
essor is the memory address space 
from 0 to 16 MB minus 1 (not from 
1 MB to 16 MB minus 1, which is 
Memory Region 2). The 80286 had 
to run in either real mode or pro¬ 
tected mode; it could not combine 
the two modes. Therefore, protected 
mode had to cover the entire address 
space from 0 to 16 MB minus 1 (that 
is, both Memory Regions 1 and 2). 


From a memory address 
space perspective, the 
80386 SX processor is 
identical to the 80286. 


Because existing DOS applications 
did not use protected mode, the orig¬ 
inal DOS memory layout was super¬ 
imposed on the memory address 
space of the 80286, and it became 
the standard for the real mode of the 
80286. Although this enabled easy 
migration from 8088-based systems 
to 80286-based systems, the full 
capability of the new processor was 
not exploited until new software 
became available. 

As shown in Figure 2, the 80286 
generated new system requirements 
for using memory address space. The 
80286 fetched its first instruction, the 
initialization vector, from a different 
address than in the 8088 processor. 

In the 8088 processor, the initializa¬ 
tion vector was located at address 
FFFFOh in Memory Region 1 (the 
only region available). In the 80286, 
the initialization vector was located 
at address FFFFFOh in Memory 
Region 2. To provide an initialization 
vector, engineers had two alternatives. 
One was to modify the memory con¬ 


troller to provide a second set of ad¬ 
dress decodes for the system ROM, 
which contained the initialization vec¬ 
tor. (In effect, this created a logical 
shadow of the system ROM.) The 
second was to provide an additional 
ROM module with its own initializa¬ 
tion vector at address FFFFFOh. IBM 
and other manufacturers chose the 
first alternative. This avoided adding 
a second physical ROM to the sys¬ 
tem, saving cost. At the same time, 
the size of the system ROM was 
increased to 64 KB because of new 
functions in the AT. 

The result was that the second set of 
ROM address decodes required 64 
KB in the 15th MB to be occupied. 
Just as 64 KB below 1 MB were 
taken from the operating system in 
the original PC, a second 64 KB, 
below 16 MB, were taken from the 
operating system in the AT. 

To calculate the amount of memory 
address space used in the 80286 proc¬ 
essor, add system usage plus areas 
reserved for feature adapter expan¬ 
sion and the video buffer. Figure 3 
shows these calculations totaling 
448 KB. 

The maximum value of the 80286 
memory address space is 16 MB. 
Subtracting the 448 KB from 16 MB 
leaves 15.5625 MB of available mem¬ 
ory address space. Therefore, the 
most memory that users can place 
and enable in the memory address 
space for use by the operating system 
and applications is 15.5625 MB of 
RAM. But this is scarcely a limita¬ 
tion. It provided more capacity than 
most users needed, because DOS 
previously supported only 1 MB of 
memory address space. Memory 
expansion increments are small 
enough so that all unused gaps in the 
memory address space can be popu¬ 
lated without having to disable any 
expansion memory. 
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80386 DX Memory 
Address Space 

In 1987, IBM introduced the PS/2. 
The PS/2 Model 80 contains the 
80386 DX processor. In addition to 
the original 64 KB used for BIOS, 
PS/2 Micro Channel systems use the 
reserved 64 KB segment starting at 
EOOOOh (in real mode memory) for 
additional BIOS support. This brings 
the total BIOS usage to 128 KB of 
memory. 

The 80386 DX processor has a third 
memory region. Memory Region 3 
extends from 16 MB to 4 GB. The 
80386 DX processor has the same 
two modes as the 80286: real and 
protected. As in the 80286 processor, 
the 80386 DX processor cannot be in 
both real and protected modes at the 
same time. Protected mode in the 
80386 DX covers addresses up to 4 
GB. Therefore, protected mode in the 
80386 DX processor covers the en¬ 
tire memory address space, from 0 to 
4 GB minus 1. 

Because of advances in technology, 
additional memory comes in mini¬ 
mum increments of 1 MB. OS/2 and 
other new operating systems support 
more than 1 MB of memory. Adap¬ 
ters also use areas in memory above 
the 1 MB boundary for dedicated pur- 
Figure 2. 16 MB Memory Address Space of the 80286 Processor poses, similar to the feature adapter 

expansion area in Memory Region 1. 


System 
Memory 
(640 KB) 


Shadow System ROM (64 KB) 


Nonsystem Memory 


Memory Not Installed 
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System ROM - BIOS/POST (64 KB) 


Reserved for BIOS (64 KB) 


Adapter ROM/RAM (128 KB) 


Video Buffer 
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Interrupt Vectors 
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Item 

Size 

Region 

Video Buffer 

128 KB 

1 

Adapter ROM/RAM 

128 KB 

1 

System ROM (BIOS/POST) 

64 KB 

1 

Reserved 

64 KB 

1 

Shadow System ROM 

64 KB 

2 

TOTAL 

448 KB 



Figure 3. PC AT Memory Dedicated or Reserved for System Functions 


All these new capabilities affect the 
memory address space map for the 
80386 DX. With the introduction of 
Advanced BIOS (ABIOS), video on 
the system board, and extensions to 
POST, the 64 KB area of system 
ROM on the AT had to be expanded. 
The logical choice for expanding sys¬ 
tem ROM was the 64 KB reserved 
area in memory starting at EOOOOh, 
which immediately precedes the area 
occupied earlier by system ROM 
starting at FOOOOh. Introduction of 
Memory Region 3 caused the shadow 
of the system ROM to be moved 
from Memory Region 2 to the top 
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System 
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(640 KB) 


Shadow System ROM (128 KB) 


Nonsystem Memory 


Memory Not Installed 


System Memory 


Nonsystem Memory 


Memory Not Installed 


System Memory 


System ROM - n 

BIOS/POST (128 KB) 


Adapter ROM/RAM (1 28 KB) 


Video Buffer (128 KB) 


Extended BIOS Data Area (1+ KB) 


System Memory 
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Figure 4. 4 GB Memory Address Space of the 80386 DX Processor 


128 KB of Memory Region 3. Figure 
4 shows the details. 

Memory increments of 1 MB caused 
the physical memory in Region 1 to 
be split into a 640 KB and a 384 KB 
block. The 384 KB block is the split 
memory block . 

Because of the limited area in Mem¬ 
ory Region 1 for feature adapter ex¬ 
pansion, adapters started using space 
in Memory Region 2. Using that 
space for adapters and devices results 
in reduced system memory available 
in Region 2. Under certain condi¬ 
tions, additional system memory may 
be lost, depending on the starting ad¬ 
dress for space dedicated to adapters 
and devices, and how much system 
memory is present. 

For example, consider a PS/2 system 
populated with 16 MB of physical 
memory. Logically, this means that 
15 MB of system memory is located 
in addresses from 0 to 640 KB and 
from 1 MB to 15.375 MB. Now sup¬ 
pose we want to add an Extended 
Graphics Array (XGA) display 
adapter to the computer. The installa¬ 
tion program for the XGA adapter 
requests a 1 MB window starting at 
address 14 MB. But system memory 
is populated up to 15.375 MB, so 
1.375 MB of system memory must 
be given up to provide space for the 
XGA window. Of the 1.375 MB, 1 
MB must come from existing system 
memory, and the 0.375 MB is the 
384 KB split memory block (0.375 
MB = 384 KB). 

The split memory block does not con¬ 
flict with the XGA adapter memory. 
However, in each of the Memory 
Regions (1,2, and 3), no system 
memory can be located above the 
start of nonsystem memory. Here, the 
XGA memory window is nonsystem 
memory, so the 0.375 MB split mem¬ 
ory block also must be considered 
nonsystem memory. 


Memory Utilization 

Figure 5 shows the memory reserved 
for system usage in 80286-based 
Micro Channel systems; Figure 6 
shows the memory reserved for sys¬ 


tem usage in 80386 DX-based Micro 
Channel systems. 

The memory utilization maps in Fig¬ 
ures 5 and 6 can lead one to believe 
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Item 

Size 

Region 

Video Buffer 

128 KB 

1 

Adapter ROM/RAM 

128 KB 

1 

System ROM (BIOS/POST) 

128 KB 

1 

Shadow System ROM 

128 KB 

2 

TOTAL 

512 KB 



Figure 5. Memory Dedicated or Reserved for System Functions in 80286-Based PS/2s 


Item 

Size 

Region 

Video Buffer 

128 KB 

1 

Adapter ROM/RAM 

128 KB 

1 

System ROM (BIOS/POST) 

128 KB 

1 

Shadow System ROM 

128 KB 

3 

TOTAL 

512 KB 



Figure 6. Memory Dedicated or Reserved for System Functions in 80386 DX-Based Micro 
Channel Systems 


that 15.5 MB of memory are avail¬ 
able in 80286-based systems, and 
that 3.9995 GB are available in 
80386 DX-based systems. However, 
this is not the case. 

In 80286-based systems, the 16th 
MB is totally lost for use as system 
memory because of the shadow sys¬ 
tem ROM. Specifically, an additional 
896 KB are unavailable for use by 
system memory because expansion 
memory comes in 1 MB increments. 
This reduces the amount of available 
system memory from 15.5 MB to 
14.625 MB. Under certain condi¬ 
tions, the split memory block remain¬ 
ing from the split in Memory Region 
1 can be remapped into Memory 
Region 2. If a remapping occurs, this 
brings the system memory total to 
15 MB. For example, PS/2 Models 
80-041 and 80-071 remap the 384 
KB split memory block from Mem¬ 
ory Region 1 to Memory Region 2. 

The 80386 DX-based systems, with 
4 GB of memory, are similarly man¬ 
aged. Only a small percentage of 


memory address space is lost com¬ 
pared to the vast available space, so 
the precise math is insignificant. This 
article does not concentrate on deter¬ 
mining what kinds of memory to use 
in 80386 DX-based systems. 

Beginning with PS/2 Model 80-111, 
PS/2 systems copied the system 
ROM to RAM to improve system 
performance. The RAM space was 
obtained by reclaiming 128 KB from 
the split memory block. This reduces 
total system memory by 0.125 MB, 
leaving a maximum of 14.875 MB of 
system memory enabled in the mem¬ 
ory address space. This is also true of 
PS/2 Models 90 and 95, which have 
Initial Machine Load (IML) capabil¬ 
ity. In these systems, the 128 KB is 
used by the system to contain the 
IML image instead of the ROM 
BIOS image. However, the addition¬ 
al loss of the 128 KB in an 80486 
memory space compared with the 
vast available space is so small that it 
does not warrant performing the cal¬ 
culations for the remaining maxi¬ 
mum capacity. 


80386 SX Memory 
Address Space 

Next, the 80386 SX processor was 
introduced. Because the 80386 SX 
memory address space is identical to 
80286 memory address space, all the 
previous information about 80286 
memory address space applies to the 
80386 SX. 

The memory address space in an 
80286-based system cannot be fully 
populated with system memory, be¬ 
cause some memory address space 
must accommodate nonsystem mem¬ 
ory for adapters and reserved areas 
for system use, such as system ROM. 
This also holds true for 80386 SX- 
based systems. 

This is why the operating system and 
applications can access and use only 
15 MB of the 16 MB memory address 
space in 80386 SX-based systems. 

With this knowledge, users can 
decide what kinds of memory to use 
to populate the memory address 
space in an 80386 SX-based system. 
There can be a maximum of 15 MB 
of RAM system memory. The 
remaining memory address space is 
populated with nonsystem memory. 
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OS/2 2.0 Installation and 
Performance Considerations 

Ron Morrill 
IBM Corporation 
Roanoke, Texas 

and 

Ron Cadima 
IBM Corporation 
Boca Raton, Florida 

This article and the article “OS/2 Application Support” in this issue dis¬ 
cuss the improvements in OS/2 2.0 compared to OS/2 IX; what they mean 
to users; and how to take advantage of them to tune systems for improved 
performance and usability 1 . Several major aspects of OS/2 2.0 are dis¬ 
cussed , including installation, performance optimization , system internals , 
and application support. Installation subjects range from pre- through 
post-installation , and include LAN-based installations of OS/2 2.0. Perfor¬ 
mance optimizations discussed include improvements to the file systems , 
the lazy write capability , the flat memory model , and the paging system. 
OS/2 system resources and limits are listed in a chart that compares OS/2 
1.3 and OS/2 2.0. 


O S/2 2.0 sets new standards for 
function, resource, and usabil¬ 
ity. By taking advantage of the 
Intel 80386 and 80486 processor 
architectures, OS/2 2.0 applications 
can gain significant performance 
improvements over earlier versions 
of OS/2. The Presentation Manager 
(PM), file systems, and other por¬ 
tions of OS/2 take advantage of the 
32-bit addressing capabilities of the 
386 and 486 hardware architectures. 
This, in turn, greatly increases the 
number of system resources - tasks, 
threads, files, and so on - that are 
available to programs running under 
OS/2 2.0. 


Pre-Installation 

Considerations 

Before you decide how to set up an 
OS/2 2.0 system and how installation 
should proceed, read the README file 
that is shipped with the system. This 
file contains updated information that 
is not in the manuals, about subjects 
such as system tuning, functions and 
applications that do not work, and 
error recovery. 

Before installing a system, you should 
know which applications will be run¬ 
ning, their disk storage requirements, 
the amount of space required to save 
data, and your plans for future 


growth. You also should know if the 
applications run on a LAN with all 
the programs and data stored on a 
server, or if the programs and data 
are stored on a local hard disk. Other 
factors in the operating environment 
include whether you run DOS and 
Windows applications; what kinds of 
OS/2, DOS, and Windows applica¬ 
tions you run; when applications are 
run; and whether any applications 
run concurrently. 

The Boot Manager, a major new fea¬ 
ture in OS/2 2.0, enables you to have 
multiple operating systems installed 
in the computer, and allows you to 
select which operating system to 
boot. This is helpful when migrating 
from OS/2 1.3 to OS/2 2.0. 

Assume that you are migrating disk 
partitions from OS/2 1.3 to OS/2 2.0. 
When you set up the hard disk with 
the Boot Manager, create the follow¬ 
ing in this sequence: 

1. One partition for the OS/2 1.3 sys¬ 
tem and another partition for OS/2 
2.0. The first partition should be 
allocated to the most-used operat¬ 
ing system. Create all the parti¬ 
tions needed for operating systems 
before proceeding to the next step. 

2. At least one partition for applica¬ 
tions and data. Again, allocate the 
first of these partitions to the most- 
used programs and data, and cre¬ 
ate all the partitions needed for 
applications and data before 
proceeding to the next step. 

3. The Boot Manager partition at the 
upper end of the hard disk. Locat¬ 
ing the Boot Manager partition at 


1 If you have access to CompuServe®, IBM’s National Solutions Center (NSC) BBS in Atlanta, or the OS/2 BBS, you should also refer to the OS/2 
Tips and Techniques and the IBMOS2 forums that are available on them. These sources will give additional up-to-date information about OS/2 and its 
use. For more information about IBM’s bulletin boards, contact your IBM representative. 
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the upper end reduces the seek 
time to all partitions that precede it. 

It is best to have separate partitions 
for operating systems and for pro¬ 
grams and data. This affords a level 
of security and data integrity because 
it reduces the chances that you will 
corrupt data when you apply operat¬ 
ing system upgrades. Sometimes you 
may see improved performance be¬ 
cause of the separate partitions. A 
third consideration is that if you are 
migrating from OS/2 1.3 to OS/2 2.0, 
and you decide that you are satisfied 
with OS/2 2.0 and no longer need 
OS/2 1.3, simply reformat the OS/2 
1.3 partition and reclaim that disk 
space without concern about losing 
any data. 

You also will want to use the Boot 
Manager if you install OS/2 2.0 on a 
computer that has DOS and Micro¬ 
soft Windows 3.1 already installed. 
Although the dual boot facility of 
OS/2 1.3 is still supported within 
OS/2 2.0, there have been problems 
with using it after installing OS/2 2.0 
on a computer that already had DOS 
5.0 and Windows 3.1 installed. To 
avoid these problems, use the Boot 
Manager to install OS/2 2.0 in a parti¬ 
tion other than the primary C: parti¬ 
tion occupied by DOS and Windows, 
and ensure that the Windows .INI 
files for use under DOS are not the 
same .INI files used for WIN-OS/2 
support under OS/2 2.0. 


Figure 1. OS/2 2.0 Disk Storage Requirements 


To use the Boot Manager on an exist¬ 
ing hard disk, you need 1 MB of free 
disk space that is not allocated to any 
disk partitions. If 1 MB of free disk 
space is not available, you will have 
to reformat your disk to free up 1 MB 
of space. Remember that when a disk 
is reformatted, any partitions that are 
deleted and re-created lose all the 
data that was stored in them. There¬ 
fore, choose the partition with the 
least amount of data stored in it, and 
be sure to back up the data in the par¬ 
tition so it can be restored. Although 
the Boot Manager partition should be 
at the upper end of the hard disk, it 
can be placed anywhere on the disk. 
You probably will want to place the 
Boot Manager partition at a location 
other than the upper end, if the upper 
end is already occupied by a for¬ 
matted partition containing data. It 
would be easier and more sensible to 
allocate the Boot Manager partition 
to available space elsewhere on the 
disk than to back up all data on the 
hard disk, reformat the entire hard 
disk, then restore all data to the disk. 

The Boot Manager will support mul¬ 
tiple physical disks, but it must reside 
on the disk from which you boot, and 
it must be marked as startable. You 
can create the Boot Manager parti¬ 
tion only by using the FDISK.COM or 
FDISKPM. EXE programs that are 
shipped with OS/2 2.0. FDISK.COM 


can be executed under OS/2 1.3 or 
2.0, but not under DOS. 

Whether or not you use the Boot 
Manager, you may want to consider 
creating a separate partition to con¬ 
tain updates to the operating system. 
Because the update procedure allows 
selected drives and directories to be 
maintained, you can create a test 
directory to apply the latest updates. 
Then, change the LIBPATH statement 
in CONFIG.SYS to point to this test 
directory first, and run OS/2 from the 
test directory for a time. If a problem 
arises during that time, it would be 
simple to change CONFIG.SYS back 
to the original LIBPATH and continue 
with your work. However, if all goes 
well, you can then apply the updates 
to the normal OS/2 directories. (For 
more details about LIBPATH settings, 
see the article “Cleaner Installation 
of Applications Under OS/2” in this 
issue.) 

Using a small bootable OS/2 parti¬ 
tion (about 3 MB of disk space) “off¬ 
loads” the normal OS/2 system so 
that you can update it. This circuitous 
route is necessary because it is not 
possible to update some OS/2 files 
when OS/2 is active. Booting from 
this small partition, however, allows 
updating any of the normal OS/2 
files. If you also enable this small 
boot partition to establish a LAN ses¬ 
sion or a host asynchronous commu¬ 
nication session, it may be possible 
to modify and maintain OS/2 from a 
central site. 

Figure 1 can help you determine how 
much disk space is required for an 
OS/2 2.0 system partition. 

There are several ways to reduce the 
amount of disk space needed by OS/2: 

• Use selective installation to 
choose which OS/2 features will 
occupy hard disk space. 


OS/2 Installation Option 

Disk Space Required 

Default Installation 

27 MB 

Preselected Installation 

21 MB 

Selective Installation with no options selected 

13 MB 


Note: These numbers cover only the OS/2 components. To these numbers, add at least 
6 MB for the swap file and 5 MB for buffer space for new functions and maintenance 
fixes. If you install the Boot Manager, remember that it requires 1 MB of disk space. 
Also, if you intend to install Extended Services (ES) 1.0 or LAN Server (LS) 2.0, you 
must allocate sufficient space in the OS/2 partition for the files they will add. Refer to 
the ES and LS Installation and Planning Guides for more information. 
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• In a LAN environment, move some 
OS/2 files from the computer’s 
hard disk to the LAN server. 

• Install only the fonts that will be 
needed. 

• Do not install all the available 
productivity programs and games. 

• Do not select options (such as 
asynchronous communications) 
that you will not use. 

• Allocate less disk space for the 
OS/2 swap file, because the more 
memory the computer has, the less 
disk space is needed for OS/2. The 
swap file acts as an extension of 
physical memory, so the more 
actual memory, the smaller the 
swap file can be. 

During installation of OS/2 2.0, the 
system automatically sets the size of 
the swap file based on the amount of 
physical memory in the computer. 
Figure 2 shows the various space allo¬ 
cations for the swap file. 

The initial size of the swap file is 
defined by the second parameter on 


Real Memory Size 

Swap File Size 

4 MB 

6 MB 

5 MB 

5 MB 

6 MB 

5 MB 

7 MB 

4 MB 

8 MB 

4 MB 

9 MB 

3 MB 

10 MB 

3 MB 

11+ MB 

2 MB 


Note : When OS/2 boots, it tries to give 
its swap file the size specified in 
CONFIG.SYS. If there is not enough free 
disk space available, OS/2 starts with a 
512 KB swap file, and dynamically in¬ 
creases the size of the swap file until it 
becomes large enough for OS/2 to initial¬ 
ize - that is, to be up and running. 

Figure 2. Swap File Space Allocation 


the SWAPPATH statement in the 
CONFIG.SYS file; the threshold for 
the swap file is defined by the first 
parameter. If the amount of free 
space left for the swap file is below 
the threshold, OS/2 warns that it is 
running out of space and suggests 
closing some active applications. The 
following line defines a swap file ini¬ 
tialized to 2 MB with a threshold of 1 
MB. 

SWAPPATFHC:\0S2\SYSTEM 1024 
2048 

These numbers are for general use. If 
you always run specific applications 
and tasks, you should change the 
initial swap file setting to meet your 
actual usage. For example, if you 
look at the size of the swap file after 
completing a normal work day and 
see that it is 10 MB, change the 
SWAPPATH statement to the following: 

SWAPPATH=C:\0S2\SYSTEM 1024 
10240 

Revise this setting if you change the 
amount of physical memory in the 
system, the size of the file system 
cache, or other system parameters 
that affect the amount of memory 
used by OS/2. The 10240 number 
used in the example represents the 
amount of memory allocated and 
used by OS/2 and the applications 
that could not fit in the system’s 
memory (RAM). The 10240 can be 
reduced by the amount of physical 
memory added. If the size of disk 


caches is made larger, then there is 
less memory for OS/2 and applica¬ 
tions - therefore the size of the swap 
file must increase. 

The 10240 number only defines the 
initial swap file size. It will grow to 
whatever size is needed, provided 
there is enough room in the disk parti¬ 
tion. Growing disk files slows perfor¬ 
mance, so define the initial size of 
the swap file large enough so it will 
not have to grow in size as applica¬ 
tions are run. 

Figure 3 can help you determine the 
amount of RAM required by OS/2. 

The numbers shown in Figure 3 
assume that no paging (swapping) 
occurs. To these numbers, add the 
amount of memory needed for file 
system caches. Virtual Disks 
(VDISKs), additional device drivers 
and buffers, expanded memory, 
extended memory, and DOS Protect 
Mode Interface (DPMI) memory. 
Because it is assumed that no page 
swapping occurs, you must add the 
amount of memory required by the 
applications. The numbers specified 
for DOS compatibility and Windows 
compatibility are for single sessions. 
If you run multiple concurrent ses¬ 
sions, multiply those numbers by the 
number of concurrent sessions. Also, 
you must total the expanded, extended, 
and DPMI memory for each of those 
sessions. The performance buffer is 
extra memory for loading applica- 


Function 

Memory 

Base code 

2.5 MB 

DOS compatibility 

0.6 MB 

Windows compatibility 

1.0 MB 

High Performance File System (HPFS) 

0.5 MB 

Spooling (while printing) 

0.5 MB 

Performance buffer 

0.5 MB 


Figure 3. OS/2 Memory Requirements 
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tions and switching screens. There 
will be little or no noticeable perfor¬ 
mance degradation when memory is 
overcommitted (that is, when the 
operating system and applications 
require more physical memory than 
the computer has available) by only 
5% to 10%. These numbers are not 
guaranteed to be valid in all user 
environments. 

Installation Process 

There are several options for install¬ 
ing OS/2 2.0. You can install it from 
diskettes using the menu-driven in¬ 
stall procedure or through a LAN. The 
server can be an OS/2 LAN server, a 
Novell server, or any other server 
system that supports TCP/IP. For 
detailed information about available 
installation functions, and about set¬ 
ting up for LAN installation of OS/2 
2.0, refer to OS/2 2.0 Remote Installa¬ 
tion and Maintenance (GG24-3780) 
and the LAN Installation Utility 12 
(LIU 12) User Guide and Reference 
(SNMS-0001-00). 

Using a response file can make instal¬ 
lation easier. The response file simu¬ 
lates the responses given by a human 
operator to installation questions and 
options. The file RSPINST.EXE in the 
\0S2\INSTALL subdirectory allows 
you to install OS/2 2.0 on a LAN 
using a predefined response file as 
input. Its input is the name of a 
response file. The file SAMPLE. RSP, 
also in the \0S2\INSTALL subdirec¬ 
tory, contains information about the 
different options available. When 
specifying these options, a zero repre¬ 
sents the default value (no option is 
selected), and a 1 selects a specific 
option or all available options. For 
example, to choose which system 
utilities to install, 0 means install 
none, 1 means install all, and a third 
option is to select the number of each 
individual utility to install. When 
multiple options are selected, they 
should be separated by a comma. 


Following are some of the more im¬ 
portant available installation options: 

• AlternateAdapter. Specifies a 
secondary display adapter. 

• BaseFileSystem. Specifies the file 
system that will be used to format 
the root directory if the Format 
Partition option is chosen. The 1 is 
for High Performance File System 
(HPFS) and 2 is for File Alloca¬ 
tion Table (FAT). 

• DefaultPrinter. Specifies the 
default printer to be installed for 
the system. The first printer diskette 
shipped with OS/2 2.0 contains a 
file called PRDESC. LST. Browse 
this file with a program that dis¬ 
plays line numbers, find the line 
number of the printer you want, 
and use that number as the default 
in the Defaul tPri nter statement. 
For example, Defaul tPri nter=5 
will install the Apple® Laser¬ 
Writer® II NT printer driver. OS/2 
2.0 Remote Installation and Main¬ 
tenance has a table of the printer 
drivers and their index numbers. If 
printers are added to or deleted 
from the list, use the line numbers 
in the PRDESC. LST file. 

• DOSEnvironment. Specify this 
option if DOS or Windows appli¬ 
cations will be run. 

• WindowedWIN-OS/2. Specify 
this option to run Windows appli¬ 
cations from the OS/2 desktop in 
a seamless manner. If it is not 
selected, you can run Windows 
applications only from a full¬ 
screen environment. 

• WIN-OS/2Desktop. Specifies 
whether you want a new WIN-OS/2 
desktop or one that is copied from 
an existing Windows desktop. 
Together with this option, you can 
use the ExistingWindowsPath 
and ShareDesktopConf igFi 1 es 
options to directly link the WIN- 
OS/2 desktop and the Windows 
desktop. Important: These options 


should be used only if you have 
Windows 3.0 installed on the com¬ 
puter. Do not use these options 
with Windows 3.1 , because they 
will corrupt either the Windows 
3.1 or the OS/2 2.0 installation. 

• DPMI. Select this option if WIN- 
OS/2 support is installed or for 
any DOS applications that use 
DPMI. DPMI is a protocol for 
how DOS applications access and 
use memory above 1 MB in a 
protected environment. 

• EarlyUserExit. Specify this op¬ 
tion with the name of a command 
file or executable program to per¬ 
form initialization steps before the 
installation starts. Use this option 
to partition the disk where OS/2 
2.0 will be installed or to save 
some files before the installation 
proceeds. OS/2 2.0 Remote Instal¬ 
lation and Maintenance includes 
an example of a REXX command 
file that partitions the disk. 

• UserExit. This option is similar to 
the previous one except that it is 
processed after OS/2 2.0 installa¬ 
tion is complete. It can be used to 
install additional printer drivers or 
applications or to restore saved 
files. OS/2 2.0 Remote Installation 
and Maintenance contains a 
sample REXX command file for 
installing additional printer drivers. 

There are additional options for modi¬ 
fying the CONFIG.SYS file; selecting 
fonts, tools, and games; installing 
device drivers; and other system 
options. Refer to the SAMPLE. RSP 
file for further information. 

When you install OS/2 2.0 by 
responding manually to the installa¬ 
tion prompts, OS/2 creates a file that 
contains your responses. This file 
called US E R. RS P is in the 
\0S2\INSTALL subdirectory. It can 
be used as a response file during sub¬ 
sequent installations of OS/2 2.0 on 
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other computers that have the same 
hardware configuration. 

The OS/2 2.0 installation process 
automatically installs HPFS support 
if there is an existing HPFS partition 
on the disk. If there are no HPFS par¬ 
titions on the disk and you have not 
done a selective installation of HPFS, 
then HPFS will not be installed on 
computers with less than 6 MB of 
memory, due to the memory require¬ 
ments of HPFS. 

The installation process also presets 
the disk cache size, based on the 
amount of physical memory in the 
computer and how much disk space 
is allocated to each file system. Fig¬ 
ure 4 shows the various disk cache 
size allocations provided by the in¬ 
stallation process. 

These cache settings should be tuned 
to the computer and operating envi¬ 
ronment. Disk-intensive applications, 
such as file servers and database 
servers, should have larger caches; 
whereas computers that perform 
much data processing or those with a 
limited amount of RAM memory 
should have smaller caches. 

Post-Installation 

Considerations 

After installation, much can be modi¬ 
fied and tuned to make OS/2 more 
efficient and productive. Most are 
changes to the CONFIG.SYS file. 
Following are several CONFIG.SYS 
options that can noticeably affect the 
performance of OS/2. 

BUFFERS 

The default for BUFFERS is 30. Be¬ 
cause of changes made to the file sys¬ 
tems, this parameter does not have as 
great an effect on performance as in 
previous versions of OS/2. The only 
time to set this parameter higher is 
when OS/2 is performing direct disk 
Input/Output (I/O), bypassing the file 
system caches. Because each buffer 


occupies about 500 bytes of system 
RAM, it is possible to free up some 
memory. For a FAT file system, 
BUFFERS can be reduced to 10, sav¬ 
ing about five pages of fixed memory 
(memory that cannot be swapped to 
disk and used for another purpose). 
For an OS/2 installation that uses 
only HPFS, or for DOS or Windows 
applications that are disk-intensive, 
BUFFERS can be reduced to 3. If you 
use file write-through, it may be 
beneficial to set BUFFERS equal to the 
number of blocks per track on the 
disk. Several DOS programs can be 
used to determine this number. One 
example is the SMARTDRV . SYS driver, 
which displays the number of blocks 
per track when booting a DOS sys¬ 
tem. Usually, cache space is used 
more efficiently than buffer memory 
and will give better performance. 

MAXWAIT 

The MAXWAIT parameter should be 
changed only if the same applications 
are always run the same way. It is 
meant to give a low-priority task 
more of a chance to run. To improve 
the priority of a task, reduce the 
value of MAXWAIT. However, be 
careful about lowering this value, 
because important tasks may get less 


processing time, adversely affecting 
the overall performance of the sys¬ 
tem. Therefore, instead of changing 
the MAXWAIT parameter, change the 
operating environment based on 
which applications you run, when 
you run them, and the order in which 
they run. If MAXWAIT is changed, it 
should be done in conjunction with 
the TIM E S LIC E parameter that can be 
added to the CONFIG. SYS file. With 
MAXWAIT=1 and TIMESLICE=50,75 
(where the two parameters on the 
TIM E S LIC E statement represent mini¬ 
mum and maximum time slices in 
milliseconds), applications visible on 
the screen will appear to run more 
smoothly and consistently. However, 
you may pay a penalty in total 
throughput. These parameters should 
be changed to meet individual 
processing requirements. 

You also should add the TIMESLICE 
parameter to CONFIG.SYS if certain 
types of DOS applications are run. 
Examples are programs that do full¬ 
screen graphics, such as games, and 
programs with a large amount of I/O 
polling, such as some communication 
packages. For these types of applica¬ 
tions, also reduce the Idle Sensitivity 
setting in the DOS session that is set 


System Memory 

Cache Sizes When Both HPFS 
and FAT are Used 

Cache Sizes When Either HPFS 
or FAT is Used 

4 MB 

128 KB and 64 KB 1 

128 KB 

5 MB 

128 KB and 64 KB 

128 KB 

6 MB 

256 KB and 64 KB 

256 KB 

7 MB 

256 KB and 128 KB 

256 KB 

8 MB 

256 KB and 256 KB 

384 KB 

9 MB 

256 KB and 256 KB 

384 KB 

10 to 16 MB 

512 KB and 512 KB 

1 MB 

17 to 32 MB 

1 MB and 1 MB 

2 MB 


1 When both HPFS and FAT are used, the larger cache size is assigned to the file 
system that has the most disk space. For example, if the hard disk is 70% allocated to 
HPFS and 30% to FAT, and the computer has 6 MB of memory, the HPFS cache is 
initialized to 256 KB and the FAT cache to 64 KB. 

Figure 4. Disk Cache Size Allocations 
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up to run the application. Start with 
TIMESLICE=64,128, then adjust the 
settings from there. Usually Idle Sen¬ 
sitivity and TIMESLICEdo not affect 
total system throughput, and they can 
improve the responsiveness of inter¬ 
active systems. This change should 
be done only if unacceptable system 
performance is encountered. 

THREADS 

This parameter controls the number 
of threads that can be used in OS/2. 
The default for OS/2 2.0 is 256. If the 
system is memory-constrained, this 
value should be calculated and 
changed. Most Presentation Manager 
applications use two or three threads 
each, so a conservative calculation 
formula is as follows: 

threads = (N x 3) + 60 

N is the number of DOS + Windows 
+ OS/2 applications. If the calcula¬ 
tion is less than 128 threads, use 128. 

If the system is running OS/2 Ex¬ 
tended Services, OS/2 LAN Server, 
or both, you should add 128 threads. 
Also, if you know that an application 
uses more than three threads, add the 
extra threads to your calculation. 

MEMMAN 

MEMMAN has several purposes. First, 
its PROTECT parameter specifies that 
OS/2 will allow protected Dynamic 
Link Libraries (DLLs) sometimes 
called Dynalinks - dynamic linking 
of data and programs in OS/2 - and 
will allow certain Application Pro¬ 
gramming Interfaces (APIs) to allocate 
protected memory. (The opposite is 
NOPROTECT.) With the SWAP (or 
NO SWAP) parameter, you can specify 
whether swapping is to occur; with 
the MOVE (or N0M0VE) parameter, you 
can specify whether memory move¬ 
ment is allowed. Memory movement 
means moving data from one place in 
memory to another. Movement is not 
allowed if an application accesses 


that data using a specific memory 
address. 

The defaults for MEMMAN are 
PROTECT, SWAP, and MOVE, and 
should normally remain that way. 
Change these parameters only if you 
run applications that you have 
developed, and if the machine has 
enough physical memory to accom¬ 
modate OS/2 and the applications. 



Most Presentation 
Manager applications 
use two or three 
threads each. 


Another parameter of the MEMMAN 
statement is NOPACK. All 16-bit appli¬ 
cations are based on a segmented 
memory model. In OS/2, each seg¬ 
ment of 4 KB or less is mapped to 4 
KB pages. For example, a 200-byte 
segment is mapped into one 4 KB 
page. Because this is very inefficient 
and can cause significant growth in 
the swap file, OS/2 2.0 packs multi¬ 
ple small 16-bit segments into a 
single 4 KB page. Depending on the 
application, this can significantly 
reduce the size of the swap file. How¬ 
ever, with some applications, a very 
small performance degradation can 
be experienced. For those cases 
where this presents a larger problem 
than increased disk usage, you can 
specify the NO PACK option in the 
MEMMAN statement. NOPACK negates 
packing multiple small 16-bit seg¬ 
ments together and causes each seg¬ 
ment, regardless of its size, to be 
mapped to a 4 KB page. 

PRIORITY 

The default setting for the P R10 RITY 
option is DYNAMIC. This setting 
should be changed only on a specific, 


dedicated system. The option 
ABSOLUTE means that the system will 
not change the priority of regular 
tasks in the system based on screen 
focus (the window on the display 
screen that you are currently using 
with the keyboard or a mouse), I/O 
activity, and frequency of processor 
use. Changing this setting to 
ABSOLUTE enables you to predict 
when tasks will run, but it can cause 
the system to appear sluggish and un¬ 
responsive. Before changing the set¬ 
ting of PRIORITY, know the priorities 
of all active tasks and be able to set 
them to meet your needs. 

SWAPPATH 

The swap path should point to the 
most used partition on the least used 
physical drive. To enhance perfor¬ 
mance, place the swap file in the 
same directory as work files and tem¬ 
porary files that are used often and 
change size frequently. This will help 
reduce fragmentation problems and 
increase the efficiency of disk acces¬ 
ses. Set the initial size of the swap 
file to the average working size in the 
environment. (Working size is the 
amount of memory and disk space 
required to run all programs and 
tasks that are normally done during 
one work day.) You also should set 
the swap threshold at 2 MB. This 
threshold will give you a minimum 
of four warnings before the system 
runs out of swap file space and you 
have to shut it down. 

PRIORITY.DISKJO 

The default for PRI0RITY_DISK_I0 
is ON. This means that the application 
running in the foreground - the one 
that the user is interacting with - gets 
a higher disk I/O priority than appli¬ 
cations running in the background. 
This action improves the response 
time of the foreground application. 
Setting PRI0RITY_DISK_I0=0FF 
eliminates the higher disk I/O prior¬ 
ity for the foreground application. 
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Path Statements 

The PATH, LIBPATH, and DPATH state¬ 
ments should be organized so that the 
most frequently used files are listed 
first and the least frequently used 
files are listed last. This sequence 
decreases the amount of searching, 
thereby improving performance. 

Note: The OS/2 2.0 installation proc¬ 
ess places . ; at the beginning of the 
LIBPATH statement. This tells OS/2 
to start its search for DLLs, fonts, 
and drivers in the currently active 
directory. Some applications modify 
the LIBPATH statement by placing 
their DLL subdirectory at the begin¬ 
ning of the LIBPATH statement. This 
can cause errors if more than one 
DLL file has the same name. After 
you install any application, including 
LAN Server 2.0, check the LIBPATH 
statement in CONFIG.SYS to ensure 
that it is correct. For more details, 
refer to the article “Cleaner Installa¬ 
tion of Applications Under OS/2 2.0” 
in this issue. 

BASEDEV=0S2SCSI.DMD 

This statement will appear in 
CONFIG.SYS if OS/2 is installed on a 
computer that supports Small Com¬ 
puter Systems Interface (SCSI) 
devices. This statement is required 
only if the system has SCSI tape 
drives, CD-ROM drives, or SCSI 
devices other than disks and diskettes. 

BASEDEV=IBM2SCSI.ADD 

This statement in CONFIG.SYS 
defines the SCSI disk device driver. 
The device driver implements the 
System Control Block (SCB) archi¬ 
tecture interface. It allows requests 
from the file system to be chained 
together in a list, so that the file sys¬ 
tem does not need to interact with the 
device driver after every request. For 
example, the file system can pass a 
request list to perform a seek, a read, 
another seek, and another read opera¬ 
tion. When the device driver com¬ 
pletes all four tasks, it passes control 


back to the file system. The number 
of interactions between the file sys¬ 
tem and the device driver is greatly 
reduced, and performance increases. 
However, in cases where immediate 
response is required - such as search¬ 
ing a database for credit authoriza¬ 
tion - it is not possible to wait for 
multiple disk operations to be per¬ 
formed before getting a response. 

Use the /GS: n parameter to specify 
how many requests the file system 
sends to the device driver in a single 
SCB list. The value of n can be be¬ 
tween 1 and 9; the default is 4. Con¬ 
sider increasing this number if the 
system is running applications that 
use work files heavily. 

SET RESTART0BJECTS=0N 

This undocumented capability, which 
is subject to change in a future 
release of OS/2, can be added to the 
CONFIG.SYS file. It determines the 
automatic startup of applications. 

The default is ON, so that any appli¬ 
cations that were active when OS/2 
was shut down are to be restarted the 
next time it comes up. If you specify 
OFF, no applications will be restarted. 
You also can specify the value 
STARTUPFOLDERONLY, which will 
restart only the applications in the 
Start folder. 


WIN-0S2 Considerations 

The “OS/2 2.0 Application Support” 
article in this issue goes into detail 
about DOS and Windows support, 
and all of the DOS settings that can 
be used to customize and optimize 
DOS and Windows sessions. Here 
are a few things that affect system 
performance with respect to DOS 
and Windows support. Many DOS 
and Windows applications perform 
device polling to see if they have any 
work waiting for them. The most 
common use is when applications are 
waiting for input from the keyboard. 
Applications enter into a software 
loop asking the keyboard device if 
the user has pressed a key. Under 
DOS and Windows, this does not 
cause a problem because only one 
application is running at a time. With 
OS/2, there may be multiple pro¬ 
grams running concurrently, which 
can cause other programs to slow 
down. To alleviate this problem, here 
are some things that can be done. 

1. Reduce the Idle Sensitivity entry 
of the DOS Session Settings to 30 
or less. This is a threshold used by 
OS/2 to determine that an applica¬ 
tion is polling a device and has no 
other work to do. By reducing this 
threshold, more time is given to 
other applications that have real 
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work to do. Change this setting 
whenever there are DOS or Win¬ 
dows applications performing 
graphics, asynchronous commu¬ 
nications, keyboard polling, or 
other types of device polling while 
running in the background. You 
must set this for each one of those 
sessions using the DOS Properties 
menu of the Sessions Settings. 

2. Memory utilization is a major 
factor when running DOS and Win¬ 
dows applications. Running DOS 
and Windows applications under 
OS/2 is equivalent to running mul¬ 
tiple DOS machines. For example, 
if you have a DOS computer using 
1 MB of memory, and another 
using 2 MB, when you bring those 
together in an OS/2 system they 
will require 3 MB total. This tends 
to make OS/2 swap RAM to disk. 
The effects of this can be lessened 
by adding aTIMESLICE parameter 
to the CONFIG.SYS file. In a mem- 
ory-overcommitted system, most 
of the application’s time slice is 
spent paging-in the memory which 
the application needs. It is benefi¬ 
cial to give the application more 
time to do its work. Try setting the 
TIMES LICE parameter as follows: 

TIMESLICE=64,128 

This says that the program will 
receive a minimum time slice of 
64 milliseconds and a maximum 
of 128 milliseconds. Depending 
on your applications, you may 
want to change either the mini¬ 
mum or maximum values to meet 
your requirements. 

Another factor to consider about 
memory is the amount of extended 
memory - DPMI, XMS, or EMS - 
that Windows applications use. If 
you are going to run multiple Win¬ 
dows applications in one WIN- 
082 session, you must ensure that 
the DOS settings for that session 
provide the total amount of 
extended memory required by all 


the applications. If three Windows 
applications are run concurrently 
under the same WIN-OS2 session, 
and each requires 2 MB of DPMI 
memory, then you must allocate 6 
MB of DPMI memory to the WIN- 
082 session. If the applications 
are running in separate sessions, 
then each session must define 2 
MB of DPMI memory. 

Refer to the DOS/Windows sec¬ 
tion in the “OS/2 2.0 Application 
Support” article in this issue for 
additional performance informa¬ 
tion and for details about all the 
DOS settings and how to set them. 



Many files can be moved 
from OS/2 clients to the 
LAN Server, where those 
files can then be used 
by all clients attached 
to the server. 


Printing 

Printing is a major concern in many 
system installations. This section 
describes some factors that affect 
printer support and performance. 

Print Servers 

Make sure that the same printer 
driver levels are on both the server 
and the workstations attached to the 
server. Print servers must run OS/2 
1.3 or later. If they are not running 
OS/2 2.0, use the printer drivers that 
are shipped with OS/2 2.0. If the 
printer drivers on the workstation and 
the server do not match, performance 
will be significantly reduced. 

Printer Data Streams 

If your printer supports fonts, ensure 
that the correct fonts are installed in 
the printer. Whenever possible, send 
raw data streams of commands and 
data to the printer. This allows a job 


to print while it is being spooled; 
otherwise, all the print data must be 
placed into the spool file before the 
printer can begin. Also, if you have a 
choice of printers, keep in mind that 
OS/2 2.0 can download fonts to a 
printer. OS/2 is aware of the printer 
and the fonts installed in that printer; 
if fonts are installed, OS/2 does not 
waste time downloading them. The 
separator page capability is new in 
OS/2 2.0. Separator pages can be 
specified in the Print Options page 
of the Printer Object settings. Two 
sample separator page files, 

PSCRIPT.SEP and SAMPLE.SEP,are 
in the \0S2 subdirectory. 

WIN-0S/2 Printing 

Windows printer drivers must be in¬ 
stalled separately from OS/2 printer 
drivers. These drivers are on the third 
printer diskette shipped with OS/2 
2.0. For drivers not shipped with OS/2, 
install the drivers that are shipped 
with Windows. You also can use the 
printer drivers shipped with Win¬ 
dows 3.1 and see some improvement 
in performance of WIN-OS/2 print¬ 
ing, as you would in a Windows 3.1 
environment. Note : This has worked 
in lab tests, but there is no guarantee 
that it will always work correctly. 

For further information about printing, 
refer to OS/2 Version 2.0, Volume 5: 
Print Subsystem (GG24-3775). 

LAN Requester Considerations 

Many files can be moved from OS/2 
clients to the LAN Server, where 
those files can then be used by all 
clients attached to the server. This 
significantly reduces hard-disk stor¬ 
age requirements of the client com¬ 
puters. It also provides an efficient 
way to limit a client’s access to cer¬ 
tain features and functions. For ex¬ 
ample, you can limit which clients 
can run DOS or Windows programs, 
which clients can run certain OS/2 
utilities such as FORMAT and FDISK, 
and which clients can access third- 
party or in-house applications. 
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The following changes make it is pos¬ 
sible to produce a client system that 
supports LAN and 3270 emulation, 
DOS and Windows, and all OS/2 
applications, while requiring less 
than 30 MB of disk space (excluding 
the SWAPPER.DAT file). The follow¬ 
ing changes are grouped according to 
the amount of work that needs to be 
done. 

The easiest is to simply move files 
from client computers to the server 
computer, and to ensure that the path 
statements are modified to point to 
files on the server. The next level of 
work encompasses the first level, and 
also includes modifying the settings 
in all OS/2 folders that are affected. 
The last step requires running various 
tests to determine which files are not 
used, then moving them to the server. 

A general rule is to keep all files that 
have extensions of . INI, . LOG, . MSG, 
.SYS, . PRO, and . DCP on the client 
computers. You should not delete 
any subdirectories, even if they are 
empty, because certain programs rely 
on having a subdirectory in a certain 
path. For all the subdirectories that 
have moved to the server, move their 
file names to the ends of the PATH 
statements. Ensure that any file 
moved to a server will not be used 
before the client computer logs onto 
the server. 

There are several ways to handle the 
startup of clients. The easiest is to 
create aSTA RTUP.CMD file that starts 
the requester and performs the logon 
function. Anything else that you 
would normally have in the 
STARTUP. CMD file should be moved 
to another command file. In this new 
. CMD file, there should be a little pro¬ 
gram that waits for the logon to com¬ 
plete before proceeding. 

Although not recommended, another 
alternative is to create a . CMD file and 
place it in the SET RUNW0RKPLACE= 
statement in the CONFIG.SYS state¬ 


ment in place of PMSHELL. EXE. This 
command file starts the requester and 
logs it onto the server, then starts the 
Workplace Shell™ by executing 
PMSHELL. EXE. This ensures that the 
client is logged onto the server 
before the Workplace Shell is started. 
For example, you could use the fol¬ 
lowing statements in a command file 
called LOGON. CMD: 

NET START REQ REM Starts 

requester code 

LOGON USERID REM USERID is 

the logon 
user ID 

PMSHELL.EXE REM Starts 

the Workplace 
Shell 

Next, modify CONFIG. SYS as follows: 

1. Add the statement 

SET SETRESTARTOBJECTS=OFF. 

2. In the statement 

SET RUNWORKPLACE=,change 
C:\0S2\PMSHELL.EXE to 
C:\START. CMD (assuming OS/2 is 
installed on the C: drive). 

There are several items to notice 
when doing this. First, there is an 
extra CMD. EXE session running in the 
system. It uses extra resources and as 
much as 150 KB of memory. Second, 
if the Workplace Shell inadvertently 


stops running, it will not automat¬ 
ically restart; the system has to be 
rebooted to bring it back. When you 
issue the Shutdown command, you 
may never see the “Shutdown Com¬ 
plete” message. For these reasons, 
and because SET RESTARTOBJECTS 
is an undocumented function, this 
method is not recommended. 

Simple File Moves 

Because many OS/2 files are rarely 
accessed, they can be moved from 
client to server. If the server is run¬ 
ning OS/2 2.0, most of these files 
should already exist on the server. 
Move all files with extensions of 
.LIB, . H, and . INC to the server. 
These files are usually required on 
the client computer only if applica¬ 
tions are developed on it. Even then, 
the PATH statements for performing 
the compilations and linkages can be 
modified to point to directories on 
the server. 

Executable files that are not defined 
in any OS/2 folders can be moved to 
the server. These files include all util¬ 
ities in the \MD0S subdirectory and 
many utilities in the \0S2 subdirec¬ 
tory. All ITelp (.HLP) files and all In¬ 
formation (. IPF) files can be moved 
to the server. When this is done, the 
SET BOOKSHELF entry must be up¬ 
dated in CONFIG.SYS to point to the 
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relevant server directory. The current 
setting of the SET BOOKSHELF state¬ 
ment in CONFIG.SYS has a list of all 
the files that can be moved. You also 
should be able to move the files that 
are in the directory pointed to by the 
SET GLOSSARY entry. 

Note : Some .LIB files, used by Easy- 
View to define screen images, should 
not be moved. Some applications 
may look for their . HLP files based 
on the installation or root directory. 
These .HLP files also should not be 
removed. 

File Moves with Modifications 

All utility files that are defined in 
folders can be moved from a client to 
the server, but you must go to the 
specific folders and modify the set¬ 
tings for those file definitions to 
point to the server directories. You 
also should ensure that any SET or 
PATH statements in CONFIG.SYS are 
updated to point to the new server 
directories. Some files, such as 
ATTRIB.EXE, COMMAND.COM,and 
APPEND.COM, are required to start 
DOS sessions, so these files cannot 
be moved to the server. 

“Brave Soul” Updates 

This applies to users who need every 
bit of space possible on the hard disk 
of the client computer. Make all the 
changes discussed above, then start 
OS/2 and all the programs that will 
be run. Next, make backup copies 
(on diskettes) of all the files in the 
LIBPATH, then delete all files with 
extension .DLL. All the .DLL files 
that are successfully deleted from the 
client computer can then be copied 
from the backup diskettes to the 
server. These .DLL files that are not 
deleted will remain where they are. 

Be sure to place the server directory 
path name in the LIBPATH statement 
in the CONFIG.SYS file. 

File Systems 

This section covers the changes that 
have been made to the OS/2 file sys¬ 


tems and tells how to take advantage 
of these changes. It also discusses the 
use of the lazy write feature under 
both the HPFS and FAT file systems. 

HPFS 

OS/2 2.0 has several significant 
internal changes to the HPFS that 
improve the performance of disk I/O 
and OS/2 in general. 

Read Ahead: HPFS provides an 
asynchronous read-ahead thread for 
files that are accessed sequentially. 
This loads the cache asynchronously, 
and improves performance because 
the next sequential record required 
by the application is already in the 
cache before the application issues 
the read request. 

Read-ahead is done only for records 
of 8 KB or less. Larger records cause 
the HPFS cache to fill up with the 
records from only one file, and I/O 
performance degrades for all other 
files. Records larger than 8 KB are 
still placed into the cache if they are 
smaller than the cache threshold. 

Disk Device-Driver Strategy Pro¬ 
tocol: The SCB protocol for support 
of SCSI devices is new in OS/2 2.0. 
This allows command chains to be 
sent to the disk device driver and sup¬ 
ports the scatter/gather capabilities of 
Direct Memory Access (DMA) bus- 
master devices. There is emulation 
for this protocol for Enhanced Small 
Device Interface (ESDI) devices. The 
file system looks at the type of 
device being used. If it is an ESDI 
device, it will try to obtain con¬ 
tiguous memory for the operation 
and use a type of STRAT 1 interface 
to the device. (If contiguous memory 
cannot be obtained, the normal emu¬ 
lation path will be performed.) In a 
STRAT 1 interface, all data being 
written to a disk must reside in a con¬ 
tiguous memory block. Data is trans¬ 
ferred from this block in sections of 
64 KB or less, because that is the 
maximum size of DMA requests that 


ESDI devices can handle. Each trans¬ 
fer must be requested separately; 
transfers cannot be chained together 
in a request list. 

HPFS Cache Threshold: The cache 
threshold parameter for HPFS is also 
new in OS/2 2.0. This parameter, in 
the IFS statement in CONFIG. SYS, 
specifies the size of the largest record 
that will be cached. The default is 4, 
which denotes 4 KB. Care should be 
used when setting this parameter. It 
should be set equal to the size of the 
record that is used most often. If the 
system primarily accesses two files, 
one with 8 KB records and one with 
4 KB records, set the cache threshold 
value to 8. If another file is accessed 
with 64 KB records, increase the 
cache threshold only if that file is 
accessed more frequently than the 
other files, and if individual records 
are accessed more than once. If this 
is not the case, keep the cache thres¬ 
hold low so that the more frequently 
used records do not get pushed out of 
the cache. 

The size of the HPFS cache should 
be set based on the amount of physi¬ 
cal memory in the computer, the 
types and frequencies of disk I/O, 
and the application mix that will be 
running. HPFS requires more memory 
to support it than the FAT system 
requires. You must use a different 
approach to setting the cache size in 
HPFS than for FAT. HPFS requires 
approximately 350 KB of memory. 
OS/2 2.0 initializes the HPFS cache 
based on the amount of available mem¬ 
ory. If you plan to run DOS/Windows 
applications or large OS/2 applica¬ 
tions, it may be more beneficial to 
reduce the cache size and to provide 
more real memory for these applica¬ 
tions. However, if you run smaller 
applications or applications that pri¬ 
marily perform disk I/O, it may be 
more beneficial to allocate a larger 
cache size. If a hard disk or partition 
has less than 60 MB, you may choose 
not to use HPFS because it would 
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leave less memory for files, negating 
any performance gains over a FAT 
system. 

If the amount of memory required for 
HPFS is too much for the machine, 
or if you choose not to use HPFS 
because disk partitions are small, use 
the Selective Install option when 
installing OS/2 to deselect the HPFS 
option. 

If the size of the HPFS cache or the 
cache threshold must be changed in 
CONFIG.SYS, do it after OS/2 installa¬ 
tion is complete. 

Other changes have been made to 
HPFS to improve disk I/O operations, 
to improve DosQueryPathlnfo 
processing, and to improve cache 
processing. HPFS supports direc¬ 
tories up to 512 GB in size and file 
sizes greater than 2 GB. HPFS does 
not yet support files that span multi¬ 
ple hard disks. 

FAT 

OS/2 2.0 has several significant chan¬ 
ges to the FAT file system. The most 
significant are the lazy write and 
sequential read-ahead capabilities 
found in HPFS. Lazy writing is cov¬ 
ered in the next subsection because it 
is basically the same for both HPFS 
and FAT. The sequential read-ahead 
capability is the same as in HPFS, 
except that 16 KB read-aheads are 
performed for FAT. The use of differ¬ 
ent strategies for interfacing to disk 
device drivers is the same as in 
HPFS. From an application point of 
view, no changes have been made to 
the APIs that are used to interface to 
the file system, except that now the 
write-through parameter has meaning 
for the DosOpen API - it allows an 
application to write directly to the 
file on the disk and to bypass the 
cache. 

FAT Cache Threshold: FAT pro¬ 
vides a way to specify a cache thres¬ 


hold parameter, which allows you to 
tell the FAT file system how large an 
I/O operation to cache. It is defined 
as a number of 512 KB sectors be¬ 
tween 1 and 128. This number should 
be based on the size of the cache and 
the size of the I/O blocks being trans¬ 
ferred. It should be as large as the 
largest block of data that is processed, 
and should not exceed one-fourth of 
the total cache size. For example, if 
the cache size is 64 KB, set the cache 
threshold at 32; for 128 KB, use 64; 
and for more than 128 KB, use 128. 
These numbers are guidelines for 
improving the performance of appli¬ 
cation I/O and application loads. The 
actual setting will vary, depending on 
the actual application mix. For ex¬ 
ample, if OS/2 is used only for data¬ 
base operations with I/O in 8 KB 
blocks, then the optimal threshold set¬ 
ting is probably 16. This would cover 
the maximum I/O size and enable the 
greatest number of data blocks to be 
cached. 

The size of the cache threshold is 
specified by a parameter in the 
DISKCACHE statement in the 
CONFIG.SYS file. If no value is 
specified, a default of 4 is used. For 
example, here is the DISKCACHE state¬ 
ment for a 256 KB cache and a cache 
threshold of 32 KB (the null field 


between the two commas pertains to 
lazy writing). 

DISKCACHE-256,,32 

Lazy Writing 

The lazy write capability is available 
in OS/2 2.0 for both the FAT and 
HPFS file systems. Lazy writing is a 
way to delay physical disk I/O writes 
until a time when the write operation 
will have little impact on the rest of 
OS/2. The application writes records 
into the cache and regains control im¬ 
mediately. When the disk is not busy 
with other tasks, or when the cache 
has too many updated (also called 
dirty) blocks in it, the physical I/O 
will be done asynchronously by 
another processing thread. Lazy writ¬ 
ing can improve the performance of 
write operations by 20% to 40%, 
depending on the type of I/O and the 
hardware being used. 

HPFS: To start the lazy writer and al¬ 
locate its associated control blocks in 
previous releases of OS/2, there had 
to be a RUN=CACHE. EXE command in 
CONFIG.SYS. This created extra sys¬ 
tem overhead. In OS/2 2.0, during 
system startup, the STARTLW.DLL 
statement in the OS2.1NI file loads a 
DLL that starts the lazy writing capa¬ 
bility under HPFS. The default is to 
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start the lazy writer. The lazy writer 
can be turned on or off any time by 
issuing the CACHE command from a 
command prompt or a command file. 
You also can add the statement 
RUN=CACHE.EXE to CONFIG.SYS to 
turn lazy writing off when the system 
is booted. 

FAT: To use the lazy writer under 
FAT, put the LW parameter on the 
DISKCACHE statement in the 
CONFIG.SYS file. The following 
statement turns on the lazy writer: 

DISKCACHE=256,LW 

Unlike HPFS, once lazy writing is 
turned on under FAT, there is no way 
to turn it off unless you change the 
CONFIG. SYS file and reboot the 
computer. 

There are three parameters for tuning 
the lazy writing process, as follows: 

MAXAGE: The MAXAGE parameter 
specifies the maximum amount of 
time in milliseconds that an updated 
data block can remain in the cache 
before it is written to disk. The 
default is five seconds. For critical 
data, this parameter can be reduced 
to a half second or less, but be aware 
that the overhead of the lazy writer 
can degrade performance if the 
MAXAGE parameter is too low. It 
would be better if the application can 
specify file write-through when the 
critical data file is opened. This is 
done by setting a parameter bit in the 
DosOpen command in the applica¬ 
tion. This bit tells the HPFS or FAT 
to read from and write to the physical 
disk directly, instead of going 
through the cache. Although this 
operation is slower than using the 
cache, it provides the most data 
security. 

DISKIDLE: The DISKIDLE param¬ 
eter specifies the amount of time in 
milliseconds that the disk is idle. If 
the disk is idle for this amount of 


time, updated data blocks in the 
cache are written to the disk. The 
default time is one second. Anything 
less than that may cause interference 
with the rest of the system. In special 
cases, a smaller number may be bet¬ 
ter for performance reasons. If much 
read I/O is being performed and oper¬ 
ator response time is critical, you 
may want to increase the disk idle 
time. 

BUFFERIDLE: If no records are 
passed into or out of the file system 
buffer during the time (in milli¬ 
seconds) specified by the value in 
BUFFERIDLE, then OS/2 starts to 
write updated records from the cache 
to the disk. The default is a half 
second. 

All these parameters have defaults 
for optimum performance in general 
environments. They should be tuned 
only for specific circumstances 
where the operating procedures are 
known and the level of data security 
can be defined. The parameter set¬ 
tings should not be reduced for sys¬ 
tems that have much ongoing swap 
activity. Reducing the values would 
cause contention problems on the 
disk between the cache program and 
the page swapper, and would degrade 
the computer’s overall performance. 

The MAXAGE,DISKIDLE,and 
BUFFERIDLE parameters are specified 
in the CACHE command for the HPFS 
file system; they can be changed 
while the system is running. There is 
no way to change these parameters 
for the FAT file system. 

OS/2 System Internals 

This section discusses three aspects 
of OS/2 2.0: flat memory model, pag¬ 
ing systems, and system resources. 

Flat Memory Model 

Previous versions of OS/2 and all 
versions of DOS require application 
programmers to treat their data as ar¬ 
tificially sized units called segments. 


This restriction forced developers to 
adopt techniques for managing these 
segments, and resulted in programs 
that were complex and not compat¬ 
ible with other platforms. 

OS/2 2.0 allows application devel¬ 
opers to allocate data objects of up to 
448 MB. Additionally, it gives devel¬ 
opers extensive control over how the 
system manages the real hardware 
resources devoted to these objects. 
Developers are free to use the large 
data addressing capability of the sys¬ 
tem - and without excessive system 
resources - to manage these objects. 

OS/2 2.0 also allows application pro¬ 
grams to be much larger than in pre¬ 
vious versions. The artificial limits 
imposed by OS/2 l.X and by DOS, 
in some cases, forced developers to 
segment their application code in 
ways that were not compatible with 
the application logic. 

The 80386 and 80486 processors 
implement memory management 
using a flat object addressing scheme. 
Objects can range from 1 byte to 4 
GB, and there can be up to 16,384 ob¬ 
jects. OS/2 2.0 uses a single object of 
up to 4 GB. In this space, application 
programs can address up to 512 MB, 
but 64 MB are reserved for shared 
objects. Applications can use the 
remaining 448 MB for private code 
and data. (This number may be 
reduced to 384 KB because of pro¬ 
tected DLL support.) Each applica¬ 
tion receives its own copy of this 
address space. Because it uses a single 
large memory object, this imple¬ 
mentation is called the flat memory 
model. Using this model, application 
programs no longer need to load or 
change any of the segment registers, 
which simplifies application program¬ 
ming and significantly enhances per¬ 
formance. 

Paging System 

In OS/2 1.3, data is managed in units 
called segments. The developer deter- 
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mines the sizes of these segments up 
to 64 KB. Managing segments of var¬ 
ious sizes, both in memory and on 
disk, requires that the operating 
system do the following: 

• Compress real storage when a 
request for a segment was gener¬ 
ated that exceeded the contiguous 
storage available in the system. 

• Use many different sizes of space 
allocation to manage disk space 
for the segments swapped out. 

This frequently resulted in exces¬ 
sive space allocations for swapped- 
out memory. 

The need for these functions is elim¬ 
inated in OS/2 2.0, which manages 
storage and swap space in fixed-size 
units called pages. If there is a need 
for a page of memory or disk space, 
OS/2 can either find a free page 
immediately or make one available 
easily. The application requires no 
programming support. Following is 
the process required to fulfill a 
request for a new page of memory: 

1. Determine whether a free page of 
memory exists. 

2. If none exists, find the Least 
Recently Used (LRU) page. 

3. If the swap file is too small to hold 
the page, increase its size. 

4. Write the LRU page to disk. If 
more than one page exists in the 
LRU list, a maximum of eight 
pages will be written to the disk. 

5. Fulfill the request using either the 
free page found or the page writ¬ 
ten to disk. 

If an application tries to access a page 
of memory that has been swapped to 
disk, OS/2 allocates a free page as 
above, then reads the swapped page 
from disk into the free page. 

If an application frees a page, that 
page is added to the list of free pages 
(if the page is in memory), or the 
disk space occupied by the page is 


freed (if the page has been swapped 
to disk). Periodically, the swap file is 
examined to see whether it can be 
made smaller, which will be possible 
when all swapped pages placed at the 
end of the file have been freed. This 
is a significant change from OS/2 
1 .X, where the swap file would never 
shrink. 

Memory Allocation 

The term memory object identifies 
memory allocated in OS/2 2.0. Mem¬ 
ory objects can be any size between 1 
byte and 448 MB; once allocated, their 
size cannot be changed. They are 
allocated in units of one page, which 
equals 4096 bytes, and each page is 
aligned on a 4096-byte boundary. 

Memory objects can be allocated as 
shared objects, in which case they are 
allocated from the address space be¬ 
tween 448 MB and 512 MB, which is 
the space reserved for shared objects. 

Within a memory object, each indi¬ 
vidual page can have the following 
characteristics: 

• Real memory committed to it 
(Without this attribute, an attempt 
to read or write to the specified 
page results in a page fault 
exception.) 

• Read only (An attempt to store 
into a page that has the read-only 
attribute results in a page fault 
exception.) 

• Read/write 

• Contain code that is executed by 
the processor (This attribute 
implies read-only.) 

• Guard page (This is a page of 
memory that has not yet been allo¬ 
cated, but has been reserved in 
case more data must be saved than 
can fit in the page. An attempt to 
store into a page with this attribute 
results in a guard-page fault excep¬ 
tion. The storage will succeed if 


real memory was committed to the 
page before the storage attempt.) 

When coding an application, devel¬ 
opers should allocate memory using 
the DosAl 1 ocMem API for all re¬ 
quired memory. Memory can be 
allocated as either committed or 
uncommitted. Committed memory 
means that at the time the memory 
is allocated, either actual RAM or 
space in the swap file is made avail¬ 
able. Uncommitted memory means 
that the page table entries and other 
control block information needed to 
define and access memory are cre¬ 
ated, but neither RAM nor swap file 
space is allocated. When the memory 
is needed, the application issues an 
API to commit the defined memory. 
Space is then made available in 
either RAM or the swap file. In 
OS/2, it is far better for applications 
to allocate memory as uncommitted, 
then commit it as needed. This 
reduces the time necessary to allocate 
the memory, and can reduce the 
possibility of having to swap data 
between RAM and the swap file. 

It is important to note that the PM 
memory and heap management APIs 
in OS/2 1 .X are supported only for 
16-bit applications in OS/2 2.0. If a 
16-bit application is being updated, 
the developer should replace the PM 
memory and the heap APIs with the 
DosAl 1 ocMem and DosSubAl 1 ocMem 
APIs to get a true 32-bit application. 

System Resources 

Figures 5 and 6 list the major OS/2 
and Presentation Manager resources 
and their limits. The figures compare 
OS/2 1.3 and OS/2 2.0, and highlight 
the much larger capacities built into 
OS/2 2.0. 

Hardware resources and limits in 
OS/2 2.0 have not changed signifi¬ 
cantly from those in OS/2 1.3. The 
major differences are as follows: 

1. Asynchronous ports are increased 
to four for both Extended Industry 
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Resource 

OS/2 1.3 

OS/2 2.0 

Full-Screen Sessions (including Multiple 
Virtual DOS Machines or MVDMs) 

16 limit 

255 limit 


12 available 

255 available 

Virtual Input/Output (VIO) Sessions 
(includes MVDMs) 

16 limit 

255 limit 


12 available 

252 available 

MVDM Sessions 

1 limit 

255 limit 


1 available 

252 available 

Processes 

511 limit 

4,096 limit 


504 available 

4,065 available 

Threads per OS/2 System 

512 limit 

4,095 limit 


483 available 

4,065 available 

Threads per Process 

54 limit 

4,095 limit 


54 available 

4,065 available 

File Handles per OS/2 System 

65,536 limit 

65,536 limit 


65,476 available 

65,470 available 

File Handles per Process 

32,766 limit 

32,766 limit 


32,761 available 

32,761 available 

Global Semaphores (per OS/2 System) 

512 

64,000 

Private Semaphores (per Process) 

128 

64,000 

Addressable Memory per System 

16 MB 

4 GB 

Addressable Memory per Process 

16 MB 

512 MB 


Note : These numbers assume that there is sufficient physical memory and disk 
memory. They also assume that both HPFS and FAT are installed and that the lazy 
writer is active. 

These numbers represent available resources in OS/2. If these limits are reached, per¬ 
formance will degrade. 

Figure 5. OS/2 Resources and Limits 



Standard Architecture (EISA)- and 
Micro Channel-based computers. 

2. Three internal diskette drives are 
now supported. 

3. CD-ROM device driver support 
has been implemented. 

4. Inti3 disk drive support via 
CBIOS has been implemented. 
This allows users to use hard disks 
for which there is currently no 
device driver. It is meant as a tem¬ 
porary support mechanism until an 
OS/2 device driver is available. 
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Figure 6. Presentation Manager Resources and Limits 
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OS/2 2.0 Application Support 

Ron Morrill 
IBM Corporation 
Roanoke, Texas 

and 

Ron Cadima 
IBM Corporation 
Boca Raton, Florida 

Application support in OS/2 2.0 has been greatly improved over OS/2 1 .X. 
Under OS/2 2.0, all applications have the advantages of improved file sys¬ 
tems such as the File Allocation Table (FAT) and High Performance File 
System (HPFS), better implementation of system services, better use of 
hardware resources, and the replacement of segment swapping with 
paging. 

This article covers 16-bit OS/2 applications, 32-bit OS/2 applications, and 
DOS/Windows applications. 


16-Bit OS/2 Applications 

S ixteen-bit applications are writ¬ 
ten for OS/2 1 .X. They are writ¬ 
ten to conform to the segmented 
memory architecture of the 80286 
processor. Each subsequent OS/2 1 .X 
version contains the system calls 
defined in previous OS/2 1 .X ver¬ 
sions. In OS/2 2.0, all 16-bit applica¬ 
tions run as they did under OS/2 l.X. 
However, changes have been made 
in the way OS/2 2.0 performs certain 
services. This article describes these 
changes for application developers. 

Memory Allocation 

In OS/2 I .X, when a small segment 
of memory was allocated to an ob¬ 
ject, the segment was given only the 
amount of memory it needed - the 
real memory assigned to the object 
plus a small amount of overhead. 
However, in OS/2 2.0 the minimum 
unit of memory allocated to any 
object, no matter how small, is one 
page, which is 4,096 bytes. There¬ 
fore, if a 16-bit application requests a 
small segment of memory, one page 
is assigned. This minimum size 


affects 16-bit applications that allo¬ 
cate many small segments. 

If an application requests a large num¬ 
ber of segments, as applications often 
do, large amounts of real memory are 
wasted. Some examples follow: 

• Assume an application requests 10 
segments of 100 bytes each. Under 
OS/2 l.X the requests are allo¬ 
cated a total of 1,000 bytes of real 
memory, whereas under OS/2 2.0 
the requests are allocated 10 x 
4,096 = 40,960 bytes of real 
memory. 

• If an application requests 20 seg¬ 
ments of 5,000 bytes each, under 
OS/2 1 .X the requests are allo¬ 
cated 100,000 bytes of real mem¬ 
ory; under OS/2 2.0, the requests 
are allocated 163,840 bytes of real 
memory. Each 5,000-byte segment 
is allocated two 4,096-byte pages, 
or 8,192 bytes of memory; 20 seg¬ 
ments x 8,192 bytes per segment = 
163,840 bytes. 

The System Performance Monitor/2 
(SPM/2) tool can identify applica¬ 


tions that request large numbers of 
segments. One way to decrease the 
memory usage of such an application 
is to rewrite its memory management 
routines so that they fit better with 
the OS/2 2.0 allocation method. 
Applications can do this by using 
DosSubAl 1 oc or the C library 
routine mal 1 oc to allocate the small 
data areas. 

Another way to reduce memory 
usage is to use the 16-bit pack facil¬ 
ity in OS/2 2.0. This option packs 
16-bit private and shared code and 
read-only data segments. The default 
is to do packing automatically when 
the application is loaded. No action 
is required by the user or the 
application. 

Users can change the default by 
specifying a N0PACK option for the 
MEMMAN statement in the CONFIG.SYS 
file. For example, the default state¬ 
ment would change from MEMMAN= 
SWAP,PROTECT to MEMMAN=SWAP, 
PROTECT, NOPACK. This may yield a 
small increase in performance, but it 
also can increase the size of the swap 
file. Measure any gain in perfor¬ 
mance and compare that to the pos¬ 
sible growth in the size of the swap 
file. 

The change in memory segment allo¬ 
cation also causes a potential incom¬ 
patibility in analyzing problems. 
Because OS/2 l.X allocated the exact 
number of bytes requested by a seg¬ 
ment allocation request, an attempt to 
store data into, or fetch data from, 
memory that is past the end of the 
segment resulted in a trap 000D. 
Under OS/2 2.0, segment allocations 
are performed in multiples of 4,096 
bytes. If you allocate a 2,000-byte 
segment, it is placed in a 4,096-byte 
page. If the application now tries to 
access byte 2,001, the hardware will 
not generate a trap 000D exception as 
it did for OS/2 1 .X, because byte 
2,001 is within the 4,096-byte page. 
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In OS/2 2.0, you will get the excep¬ 
tion only if the size of the segment 
was a multiple of 4,096 bytes and if 
the application tried to access some¬ 
thing outside that size. For example, 
if the application allocates a 4,096- 
byte segment, then tries to access 
byte 4,097, the hardware exception 
will be generated. 

32-Bit OS/2 Applications 

New Application Programming Inter¬ 
faces (APIs) support 32-bit applica¬ 
tions. While many APIs are the same 
as their 16-bit counterparts, signifi¬ 
cant changes have been made in 
many others. 

Memory Management 

OS/2 2.0 uses the flat memory 
model, and 32-bit applications are 
written to conform to this model. It 
allows 32-bit applications to allocate 
memory objects rather than memory 
segments as in OS/2 l.X versions. 
These objects can be any size from 
1 byte to 448 MB. Applications can 
realize significant performance gains 
simply by using large memory ob¬ 
jects. In addition, by controlling their 
memory objects, applications allow 
OS/2 to make better use of real 
machine resources. 

Allocation of memory objects can be 
a two-step process. In step one, the 
application reserves address space 
for the memory object. This creates 
the entries in the page tables that 
define the memory object, but it will 
not allocate any RAM or space in the 
swap file for the memory object. The 
reserved address space is called un¬ 
committed memory. Step two of the 
process occurs when the application 
needs to use that memory. In this 
step, the application issues an API, 
DosSetMem, to commit that memory. 
Then OS/2 allocates actual RAM or 
swap file space for the memory ob¬ 
ject. When a page is first committed, 
it is filled with binary zeros. 


Here are two examples of using this 
process: 

1. Suppose an application uses a 
memory object as a linear array of 
elements. The application stores 
data into the first element, then the 
second, and so on. As it is saving 
data, the application checks 
whether the next array element 
can fit into the real memory al¬ 
ready committed. If the next array 
element cannot fit, the application 
issues a command to commit the 
next section of allocated memory. 

2. Suppose an application uses a 
memory object as a random array 
of elements. When the application 
wants to store data into an array 
element, it determines the specific 
element by using an algorithm 
such as a key value or a hashing 
technique. It then checks whether 
the corresponding page of the 
memory object has already been 
committed. If not, the application 
commits the page. 

In both cases, the application may 
later determine that a page containing 
certain elements of the array is no 
longer needed. It can then decommit 
the corresponding page of the mem¬ 
ory object. Of course, if the entire 
memory object is no longer needed, 
it can be freed using DosFreeMem. 

Significant advantage is gained in the 
above scenario only if the memory 
objects are of substantial size or are 
large in number. Remember, to 
manage objects of less than page 
size, use the C compiler’s mal 1 oc or 
DosSubAl1oc. 

It is far more efficient to allocate a 
large memory object with uncom¬ 
mitted memory, then suballocate it 
and commit the individual memory 
objects as needed. This ensures that 
you are using only the amount of 
memory that is needed. At the same 
time, it can reduce the size of the 
swap file if more application memory 


is being used than is physically avail¬ 
able in the computer. 

Optimum disk Input/Output (I/O) is 
achieved when it is performed in 
blocks of 32 KB and 64 KB. When 
allocating either I/O memory objects 
or objects that will be paged, it is 
best to allocate them to take advan¬ 
tage of the optimum I/O block size. 

The heap management APIs that ex¬ 
isted in Presentation Manager (PM) 
in OS/2 1 .X exist in OS/2 2.0 only 
for 16-bit applications. It is recom¬ 
mended that the DosAl 1 ocMem and 
DosSubAl 1 oc APIs be used. This 
should be a simple change because of 
the flat memory model, and will 
yield performance gains of 5% to 
15% over the OS/2 l.X PM heap 
manager. 

Stack Management 

A 32-bit application uses memory 
objects for its stack. A stack can be 
up to 448 MB. Real memory is not 
assigned to a stack until the applica¬ 
tion requires it. This is done by com¬ 
mitting only the last two pages of a 
stack (stacks are used from the top 
down). The lower of the two pages is 
marked as a guard page , a page of 
uncommitted memory that is not allo¬ 
cated until the data in the previous 
page overflows. When the applica¬ 
tion starts to use this page, an excep¬ 
tion is generated. As a result of this 
exception, the next lower page is 
committed and marked as a guard 
page. Thus, memory is gradually 
committed as the application requires 
it. This process ends when the mem¬ 
ory object used for the stack is com¬ 
pletely committed. 

Because stacks in OS/2 2.0 are essen¬ 
tially unlimited in size, application 
programmers can make more use of 
automatic variables. Automatic vari¬ 
ables are allocated when a function 
starts and are automatically freed 
when that function ends. Allocating 
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and freeing automatic variables is 
extremely efficient, because the mem¬ 
ory already exists in the stack, and no 
new base address must be loaded to 
access the data. 



Semaphores 

Semaphores in 32-bit applications 
have significantly changed. There are 
now two classes and three types of 
semaphores. The two classes are as 
follows: 

• Private semaphores are used 
within a single process. An appli¬ 
cation can have up to 64,000 
private semaphores. 

• Shared semaphores can be shared 
by all processes. A total of 64,000 
shared semaphores can be created 
by all processes in the system. 

The three types of semaphores are as 
follows: 

• Event semaphores allow one task 
to notify another task that some¬ 
thing has happened. Examples of 
events include when file I/O is 
complete; database retrieval is 
complete; the user has requested 
that a function be executed. 

• Mutex semaphores are designed 
to protect a common resource, 
such as a common data area used 
by more than one thread. A mutex 
semaphore protects that area from 
simultaneous update by more than 
one thread. 

• MuxWait semaphores allow a 
thread to wait for one or more of 
the above types of semaphores to 
be posted. 

All semaphore processing has been 
rewritten for the 32-bit application 
interface. Semaphore processing is 
much faster in the new application 
interface. 

Thread Management 

The ability to start and control 
threads has been enhanced in OS/2 
2.0. This makes threads easier to use 


and results in improved overall sys¬ 
tem performance. 

OS/2 2.0 supports more threads - up 
to 4,096 threads for the entire system 
(any subset of which can be allocated 
to a process). Formerly, a process 
could start no more than 53 threads. 
The amount of real memory required 
to support each thread is reduced. 


Stack allocation and freeing is done 
automatically by DosCreateThread. 
This eliminates the requirement that 
OS/2 1 .X places on the creating code 
to allocate the new thread’s stack. 

(In OS/2 1 .X, there was no supported 
way to free the stack when the thread 
ended.) 

Threads can be created in a sus¬ 
pended state. This enables an applica- 
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tion to create threads that are ready to 
perform their required functions 
before they are needed. Applications 
may therefore be more responsive to 
requests when the required function 
needs to be executed. 

At any point, the execution of a 
thread can be suspended. This gives 
an application ultimate control over 
the allocation of processor resources 
to its threads. 

Obviously, suspended threads can be 
resumed and threads created in a sus¬ 
pended state can be started. At any 
time, applications can find out about 
the current state of a thread by using 
the DosGetlnfoBl ocks API. 

Thread Priority 

Changes also have been made to 
thread priorities. The thread priority 
is now carried through to the file I/O. 
This means that threads performing 
file I/O will have that I/O serviced 
according to their execution priority. 
This improves the performance of 
timing-critical applications and appli¬ 
cations that process with foreground 
or screen focus. Because applications 
that have the screen focus get a 
higher priority in process execution, 
they also receive higher priority for 
I/O processing. 

DOS/Windows Applications 

The rest of this article describes 
considerations for running DOS 
applications under OS/2 2.0. These 
considerations also apply when run¬ 
ning Windows applications, since 
Windows applications run under the 
control of a DOS session. Not all 
aspects of this support are discussed 
here. For additional information, 
refer to OS/2 2.0 , Volume 2: DOS 
and Windows Environment (GG24- 
3731). 

Users can run up to 240 concurrent 
DOS application sessions. Like all 
other OS/2 2.0 sessions, every DOS 
session has preemptive multitasking, 


a protected environment for each 
application, and the performance ad¬ 
vantages of the new FAT and HPFS 
file systems. Generally, if an indi¬ 
vidual DOS application “hangs” its 
DOS session, that session terminates 
without affecting other DOS or OS/2 
sessions. 

Each DOS session can be provided 
with much more memory than the 
DOS Compatibility Box provided in 
OS/2 l.X: 

• More than 630 KB of standard 
memory 

• Up to 32 MB of Expanded 
Memory Specification (EMS) 
memory 

• Up to 16 MB of Extended 
Memory Specification (XMS) 
memory 

• Up to 512 MB of DOS Protect 
Mode Interface (DPMI) memory 

Each DOS session can run in any of 
the following modes: 

• Full-screen foreground: This 
mode gives the application full 
access to all video functions. 

• Full-screen background: In this 
mode, all access to video functions 
by the application must be simu¬ 
lated by OS/2. Applications run 
somewhat slower in this mode 
than in full-screen foreground 
mode. 

• In a DOS window on the Presen¬ 
tation Manager (PM) desktop: 

Cut and paste are supported in this 
mode. Users can cut any part of 
the window to the clipboard, and 
conversely can paste text informa¬ 
tion from the clipboard to the DOS 
application. All access to video 
functions by the application must 
be simulated by OS/2. The applica¬ 
tion runs somewhat slower in this 
mode than in full-screen foreground 
mode. In this mode, an application 
is prevented from executing if it 
performs XGA or 8514/A graphics 


writes to the video display. There 
may be a slowdown in your com¬ 
puter's performance if you execute 
multiple full-video applications 
concurrently. 

DOS Memory Extenders 

DOS sessions assume they have total 
control over the hardware, so they 
consume as much resource as they 
are given. If you allow each of sev¬ 
eral DOS sessions to consume large 
amounts of EMS, XMS, or DPMI 
memory, you can run out of memory 
or disk space. 

OS/2 2.0 lets you specify the maxi¬ 
mum values for EMS and XMS mem¬ 
ory to be used by all DOS sessions 
and the default values for each ses¬ 
sion. OS/2 2.0 also lets you specify 
the maximum amount of DPMI 
memory for each session. The values 
for all sessions are specified in the 
CONFIG.SYS file. 

To enable DOS sessions to use EMS 
memory, load the Virtual Extended 
Memory Manager (VEMM) device 
driver by specifying the following 
D E VIC E= statement inCONFIG.SYS 
(which assumes OS/2 2.0 is installed 
on the C: drive): 

DEVICE=C:\0S2\MD0S\VEMM.SYS 
4096 , 2048 

Here, 4096 represents the total 
amount of EMS memory available to 
all DOS sessions, and 2048 repre¬ 
sents the default amount of EMS 
memory available to each DOS 
session. 

To enable DOS sessions to use XMS 
memory, load the Virtual Extended 
Memory Support (VXMS) device 
driver by specifying the following 
statement in CON FI G. SYS: 

D EVIC E=C:\0S2\MD0S\VXMS.SYS 
4096, 2048 

As with the EMS driver, 4096 repre¬ 
sents the total amount of XMS mem- 
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ory available to all DOS sessions and 
2048 represents the default amount 
of XMS memory available to each 
DOS session. The VXMS device driver 
statement should follow the VEMM 
statement in CONFIG.SYS to prevent 
conflicts between the two drivers. 

To enable DOS sessions to use DPMI 
memory, load the Virtual DOS Pro¬ 
tection Extension (VDPX) and Vir¬ 
tual DOS Protect Mode Interface 
(VDPMI) device drivers by specify¬ 
ing the following statements in 
CONFIG.SYS: 

DEVICE=C:\0S2\MD0S\VDPX.SYS 
DEVICE=C:\0S2\MD0S\VDPMI.SYS 

No parameters are associated with 
these drivers. Because there is no sys¬ 
tem-wide limitation on DPMI mem¬ 
ory, take care when specifying the 
DPMI maximum for each DOS ses¬ 
sion. These same settings apply'to 
Windows sessions. However, there 
are some additional considerations 
for Windows sessions depending 
upon the mode in which Windows 
applications are run. 

All Windows applications can be 
executed in a common Windows 
session, either in a full-screen mode 
using the Windows Program Man¬ 
ager, or in windowed or full-screen 
sessions without the Program Man¬ 
ager. The latter are “seamless” 
sessions where the Windows applica¬ 
tions are started from an icon on the 
desktop or in an OS/2 folder. When a 
Windows application is defined, the 
user can choose (in the Settings por¬ 
tion of the session binder) whether to 
run the individual Windows applica¬ 
tion in full screen or in a window. If 
the application is to be run in a win¬ 
dow, the user can choose between a 
separate session or a common session. 

Separate sessions provide more secu¬ 
rity and can improve system respon¬ 
siveness. For example, when you run 
a Microsoft Word for Windows 


macro in a native Windows environ¬ 
ment, you may notice that it is diffi¬ 
cult to change the screen focus and to 
switch to another application. This 
same phenomenon occurs when you 
run this application in a common 
WIN-OS2 session. However, if you 
run Word for Windows in a separate 
WIN-OS2 session, you can switch 
between applications without delay. 
The separate session also improves 
data security. If the application run¬ 
ning in that session has an unrecover¬ 
able error, that session fails, but it 
does not affect any other active 
session. 

The drawbacks of having separate 
WIN-OS2 sessions are that they re¬ 
quire a lot of memory and are slow to 
start up. Starting a separate WIN- 
082 session is equivalent to booting 
a computer with DOS, starting Win¬ 
dows, then loading the Windows 
application. In addition, memory is 
needed for each of these “com¬ 
puters.” The trade-off of having 
separate WIN-OS2 sessions, there¬ 
fore, is to gain session security, per¬ 
formance, and responsiveness, while 
seeing an increase in the use of com¬ 
puter resources and slower startup of 
applications. 

With common WIN-OS2 sessions, 
session security is lost and applica¬ 
tions run as they would in a Win¬ 
dows environment. However, startup 
performance and system resource 
utilization improve. The first com¬ 
mon session Windows application 
that you load is equivalent to booting 
DOS, starting Windows, then loading 
the Windows application. But when 
subsequent Windows applications are 
loaded, you need only load the 
application. 

When the required amounts of XMS, 
EMS, and DPMI memory are defined 
for a common session, the total must 
equal the memory requirements of all 
the Windows applications that will 
run concurrently in the common 


WIN-OS2 session. For example, if 
you run three Windows applications 
in a common WIN-OS2 session, and 
each application requires 2 MB of 
DPMI memory, you must allocate 
6 MB of DPMI memory for the com¬ 
mon WIN-OS2 session. 

As soon as they are loaded, certain 
Windows applications will try to ac¬ 
cess all the DPMI memory. Depend¬ 
ing on where these applications are 
loaded, this can cause a sudden large 
growth in the swap file and can 
adversely affect performance. It is 
probably best to start these applica¬ 
tions after all others have been 
started. 

If there is a Windows application that 
you always use in the common WIN- 
082 session, it is a good idea to start 
that application right after OS/2 2.0 
is started. To start an application im¬ 
mediately, simply place the applica¬ 
tion into the Workplace Shell’s 
Startup folder. To load another Win¬ 
dows application after this applica¬ 
tion has been loaded, the DOS and 
Windows environment will not load 
again, and the application loads 
much faster. 

Another way to enhance the perfor¬ 
mance of Windows applications is to 
use a “private” clipboard and Dynamic 
Data Exchange (DDE) support. (The 
default is to use public support.) This 
means that DOS, Windows, and 
OS/2 applications can communicate 
through DDE and the clipboard, if 
they use the same protocols. If only 
the Windows applications in a com¬ 
mon Windows session need DDE or 
clipboard support, they should use 
the private support. To specify pri¬ 
vate support, perform the following 
steps after starting the common Win¬ 
dows session: 

1. Restore the clipboard program in 
the WIN-OS2 session. Select Op¬ 
tions from the action bar and de¬ 
select the Public Clipboard option. 
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2. Select the DDE Interchange Agent 
from the WIN-OS2 session and 
close it. 

3. Optionally, bring up the OS/2 
Window List and close the Data 
Update and Clipboard processes 
displayed in it. 

A common WIN-OS2 session can 
run with one or more separate WIN- 
OS2 sessions. This allows greater 
flexibility in balancing memory 
resource usage, OS/2 resource usage, 
and OS/2 system performance. 

DOS Properties 

The DOS Properties feature of Multi¬ 
ple Virtual DOS Machines (MVDM) 
gives the user the ability to selective¬ 
ly configure and tune the Virtual 
DOS Session environment to meet 
the requirements of particular appli¬ 
cations. Because some DOS applica¬ 
tions require certain features while 
other applications operate better 
without them, a Virtual DOS Session 
can be individually configured to pro¬ 
vide the optimum execution environ¬ 
ment for the application. 

The user can set DOS Properties 
when adding an application to a 
group on the desktop, or in certain 
cases, during execution while an 
application is running within the 
Virtual DOS Session. In the case 
where a Virtual DOS Session is 
created by another process using a 
DosStartSession( ) function call, a 
buffer can be provided that contains 
the required DOS Properties and 
their values. 

The following discussion covers only 
those DOS Properties that directly 
affect OS/2 or Virtual DOS Session 
performance. They let users exercise 
extensive control over the perfor¬ 
mance characteristics of the Virtual 
DOS Session. 

DOS Properties can be changed in 
either of two ways: 


• Settings that are adjustable only 
when a Virtual DOS Session is 
created can be changed only 
before starting the Virtual DOS 
Session. If the DOS application is 
placed into a folder in the Work¬ 
place Shell, the DOS Properties 
can be changed by selecting the 
Properties option in the applica¬ 
tion’s context menu. 

• Settings that are adjustable at any 
time can be set in the manner 
described above, or they can be 
changed while an application is 
running in a Virtual DOS Session. 

Certain settings can be changed both 
ways. For some DOS applications 
that exist at the time OS/2 2.0 is 
installed, the installation process 
automatically creates the DOS Prop¬ 
erties settings. Updates and new 
DOS Properties will be made avail¬ 
able on bulletin board systems, such 
as CompuServe or IBM bulletin 
boards. 

The DATABASE. TXT file in the 
\0S2\INSTALL subdirectory contains 
a list of all the applications tested by 
IBM with OS/2 2.0 and their settings. 
You can modify this file to change 
DOS settings or to add applications. 
Once the file is updated, it must be 
run through an application called 
PARSEDB, also in \0S2\INSTALL. 

This program generates a . DAT file; 
you must give this file a name other 
than the name of the existing . DAT 
file, DATABASE. DAT. The OS/2 migra¬ 
tion utility uses this new . DAT file to 
migrate and install DOS, Windows, 
and OS/2 applications. 

Even the most innocent of the DOS 
settings can affect your OS/2 system’s 
performance and resource utilization. 
For example, the DOS_LASTDRI VE 
setting defines the letter of the last 
drive that can be accessed; this set¬ 
ting affects the computer because 
every drive letter costs approximate¬ 
ly 100 bytes of memory. This may 
seem insignificant, but it can mean 


the difference between paging and 
not paging memory. 

The rest of this article covers the 
most important DOS and Windows 
settings. For a description of all the 
DOS and Windows settings, refer to 
OS/2 2.0, Volume 2: DOS and Win¬ 
dows Environment. 

Figure 1 shows settings to control 
how screen I/O operations function 
within a Virtual DOS Session. The 
settings in Figure 2 affect the virtual 
hardware environment provided by 
the Virtual DOS Session. Figure 3 
shows settings affecting the behavior 
of the DOS emulation environment 
within a Virtual DOS Session. Figure 
4 shows settings that affect the be¬ 
havior of the EMS, XMS, and DPMI 
memory extenders, if used in the Vir¬ 
tual DOS Session. Figure 5 shows 
settings that affect file I/O operations 
within Virtual DOS Sessions. Figure 
6 shows settings that affect the screen 
I/O behavior of Virtual DOS Ses¬ 
sions when running in windowed 
mode on the Presentation Manager 
desktop. 

Other Considerations 

Tools are under development for 
tuning and analyzing OS/2 applica¬ 
tions and performance. The first tool 
that will be available is SPM/2. This 
tool can be used to report processor, 
memory, and disk resource usage, 
application and OS/2 working set 
sizes, disk and file system utiliza¬ 
tions, and processor utilization. 

Remember, there are 32-bit versions 
of existing OS/2 APIs as well as new 
32-bit APIs that support new func¬ 
tions like the 32-bit flat memory 
model. Whenever an application is 
developed, these APIs should be 
used instead of the old 16-bit ones. 
Using these APIs can produce signifi¬ 
cant performance gains over a seg¬ 
mented application with a minimum 
of a 20% gain. If the design takes 
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advantage of OS/2’s features, gains 
up to 60% are possible. 

The actual gain depends on the func¬ 
tions that the application performs 
and the resources required. The more 
an application is memory-intensive, 
with large memory object processing, 
the greater the potential for perfor¬ 
mance enhancements. 

To attain the higher gain, design 
applications to take advantage of the 
flat memory model and multi¬ 
threaded execution. At a minimum, 
each application should contain three 
separate threads: one to perform I/O, 
one for mainline processing, and one 


for initialization and error handling. 
Developers should code to conform 
to the PM model and take advantage 
of the common file and font dialogs 
that are supplied with OS/2. This not 
only saves space and coding com¬ 
plexity in the application, but it en¬ 
sures that the user will work with the 
same interface for all applications 
including the OS/2 system. 

Even though a paging system is more 
efficient than a segmented system, 
and even though the flat memory 
model enables greater use of system 
resources, developers must still be 
aware of the system resources that 
they are using and minimize them as 


much as possible. This means reduc¬ 
ing the working set of the application 
environment to minimize the amount 
of paging that takes place and to max¬ 
imize the performance of the system. 
With this in mind, limit the number 
of DLLs that the application contains 
to major function areas. One DLL 
may be for initialization, termination, 
and error processing. Others should 
be built based on related functions 
that are used in conjunction with 
each other. 

When setting up the system, OS/2 
uses only the numbers of fonts, code 
pages, and device drivers that are re¬ 
quired by the environment. Be sure 


8514/A &XGA I/O Trapping 

Function: When this setting is set to on, it provides faster, unrestricted access to 8514/A display adapter hardware. 

Advantages: It achieves higher performance for 8514/A applications and eliminates the overhead of the 1 MB 8514/A virtual 
video buffer normally allocated for each Virtual DOS Session. 

Drawbacks: Screen-switching away from the application results in immediate freezing of the application, and the system may not 
be able to reliably switch back because the screen image may not be correct. This can be overcome by setting Video Screen- 
Switch Notification that notifies applications to redraw their own screen images. Not all applications can take advantage of the 
notification. An application with this setting enabled cannot be run in a windowed mode or copied to the clipboard, because there 
is incomplete information about the state of the screen buffer. 

Default: Off. 

Settable: At Virtual DOS Session creation only. 

Example: When executing Windows 3.0 with the 8514/A display driver, certain operations, such as painting dithered 
backgrounds, will run significantly faster. 

Video Mode Restriction 

Function: This setting extends the 640 KB DOS address space by limiting video-mode support. 

Advantages: For text-based or Color Graphics Array (CGA)-based applications, the video memory normally reserved for high- 
resolution graphics modes just above 640 KB can be remapped to conventional memory. This frees an additional 64 KB (or 96 
KB, depending on graphics mode) for applications. This is valuable for applications that do not take advantage of EMS or XMS 
memory extenders. 

Drawbacks: It is not possible to completely hide the fact that the video adapter is capable of high-resolution graphics; some 
applications may attempt to enable those modes and to use the memory above 640 KB as video memory, inadvertently corrupting 
the application that is using that area. Exercise care when using this feature. 

Default: None. There are three possible settings; 

• None, which defaults to the OS/2 definition. 

• CGA modes only (adds 96 KB). Only applications that support this mode can run in it. 

• Monochrome modes only (adds 64 KB). 

Settable: At Virtual DOS Session creation only.__ __ _ 


Figure 1. Video Settings (continued) 
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Video: On-Demand Memory Allocation 

Function: This setting reduces swap space requirements for full-screen Virtual DOS Sessions. 

Advantages: This setting allows a full-screen Virtual DOS Session to run without preallocating a virtual video buffer for high- 
resolution graphics modes. This setting does not prevent execution of graphics applications; allocation of the buffer is simply 
delayed until it is needed. This can save a substantial amount of memory and swap file space, which could be important when 
memory is constrained. 

Drawbacks: If the allocation of a virtual video buffer for a full-screen Virtual DOS Session fails at the time the application 
changes video modes, the system must freeze the session and switch control back to the shell. Unless the user can free memory 
from another session, the user may be unable to get the DOS application running again. This is a concern if the application 
contains unsaved data. 

Default: Off. 

Settable: At any time. Becomes effective the next time the session switches to a full screen. 

Video: Retrace Emulation 

Function: This setting simulates the video retrace status port to provide faster access. 

Advantages: DOS applications that poll the video retrace status port often write to the screen only during the retrace interval, 
even though it is safe (on EGA and VGA adapters) to draw at any time without causing “snow” interference. This feature causes 
most applications to write to the screen more often, and compensates for the performance drag imposed by monitoring the port in 
the First place. 

Drawbacks: Some applications may poll the port in such a way that overall performance is worse; this is sometimes true of 
applications that draw only during vertical (not horizontal) retrace. Unfortunately, while turning off trace emulation will restore 
performance, there is a risk that screen-switching will not be as reliable. 

Default: On. Reliable screen-switching has higher priority over the minority of applications that experience some drag in 
performance. 

Settable: At any time. This enables users to experiment with different settings if a performance problem occurs. 

Video: ROM Emulation 

Function: This setting emulates selected INT lOh Read-Only Memory (ROM) video functions. 

Advantages: This setting provides faster output for selected video functions than ROM services typically provide. It has a 
dramatic effect on the performance of functions that are in a window. 

Drawbacks: Some ROM may offer enhanced services that are not included in the emulation. Applications that rely on these 
services may not execute correctly. 

Default: On. Because the INT lOh ROM video services are well documented, incompatibilities are unlikely and the performance 
benefits of using the emulation are quite significant. 

Settable: At any time. This allows the user to experiment in the event of a compatibility problem. 

Video: Screen-Switch Notification 

Function: This setting notifies a DOS application of a switch to or from full-screen mode. 

Advantages: This setting allows applications that monitor this notification to redraw their screens as needed. This may be 
necessary for some video adapters with modes (and applications that use those modes) that are not fully supported by the OS/2 
video driver or those that are slightly incompatible. It is also valuable in situations where an OS/2 video driver has not allocated a 
virtual video buffer (see “8514/A & XGA I/O Trapping” above). 

Drawbacks: When used indiscriminately, this feature can cause unnecessary and time-consuming screen redrawing. For standard 
mono/CG A/EG A/VGA video modes, the OS/2 video driver should be able to restore application screens without assistance. 

Default: Off. For standard hardware and standard video modes, this feature is not necessary. 

Settable: At any time. This allows the user to experiment when a compatibility problem occurs. 

Example: Windows 2.X and 3.X understand this notification and redraw themselves accordingly. 


Figure 1. Video Settings 
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Break 

Function: Determines whether the operating system checks for the keystrokes Ctrl+Break or Ctrl+C while a program is 
processing. If the Break setting is enabled, pressing these keystrokes causes OS/2 to terminate the current application. 

Default: Off. The operating system checks only for Break key combinations during standard input or output operations. Programs 
run more slowly when BREAK=0N. 

Settable: At initialization time or at Virtual DOS Session creation. It is not possible to change the Break setting after a program is 
running in a Virtual DOS Session. 

Example: OS/2 checks the Break key combinations when there is input from the keyboard to the program or output from the 
program to the screen or a printer. It does not, however, check while the program is processing information (for example, while a 
program is being compiled). 

Copy ROM to RAM 

Function: Enabling this setting causes OS/2 to copy ROM and run the copy in 32-bit RAM. With this setting enabled, BIOS 
operations run faster and system utilities can patch BIOS - that is, change instructions and code in BIOS. 

Default: Off. 

Settable: At Virtual DOS Session creation only. 

Examples: This setting is useful if debugging the kernel. Copying ROM to RAM allows normal breakpoints to be set in ROM 
and allows stepping over calls and loops. WARNING: If an application writes to ROM address space while this setting is enabled, 
it could cause problems for that application and for every application run after that. 

Exclusive Mouse Access 

Function: This setting allows Virtual DOS Sessions to run applications that maintain their own mouse pointers. Some DOS 
applications manage their own mouse positions and movements; in many cases, the application's values for mouse sensitivity or 
double-speed threshold are different from those of Presentation Manager. As a result, a PM mouse pointer can be outside the 
Virtual DOS Session window while the application pointer is somewhere in the window that is not receiving any mouse events. 

Advantages: The user forces the physical mouse driver to send its events directly to the virtual mouse driver without going 
through PM. Only one mouse pointer appears when the particular Virtual DOS Session window has the focus. 

Default: Off. 

Settable: At any time from the Virtual DOS Session system menu, by selecting Properties and turning on the Exclusive Mouse 
Access setting. However, this only marks the Virtual DOS Session window; it does not actually activate the setting. To activate it, 
the user must press a mouse button within the Virtual DOS Session window. The PM pointer disappears, leaving only the 
application pointer. To regain the PM pointer, the user must press any of the hot keys (Alt, Ctrl+Esc, Shift+Esc). 

(R) 

Example: When a user runs an application such as Microsoft Windows, PC PaintBrush , or Flight Simulator, two mouse pointers 
appear in the window and may move out of sync with one another. This setting avoids such situations. 

Video: Fast Paste 

Function: Simulates user input using a faster mechanism. 

Advantages: Improves the speed of paste operations made from the clipboard to a DOS application. 

Drawbacks: Does not work with all applications; in particular, some applications that monitor keyboard interrupts directly may 
experience errors. 

Default: Off. 

Settable: At any time. This facilitates easy experimentation by the user. 

Example: Pasting into the DOS command prompt, or into any application using DOS console I/O functions, usually works. 
However, the M editor by Microsoft, and its successor. Programmer’s Workbench, can fail when using fast pasting because they 
rebuffer keystrokes in an internal buffer that can overflow. 


Figure 2. Hardware Environment Settings (continued) 
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Idle Seconds Allowed 

Function: When a program appears to be waiting for input, OS/2 gives it less time and gives preference to other programs that are 
doing useful work. Some programs periodically appear to wait for input, but then deliberately continue after a time. This setting 
disables the “idle detection” function for a period after useful work has been detected, and makes allowance for programs that 
resume after waiting. 

Advantages: If a program appears to run slowly when there is an option for the user to provide input, this value should be 
increased so that OS/2 waits longer before reducing the execution time allocation for this program. 

Default: This value is in seconds, and the default is no idle time allowed. 

Settable: While the program is running, this setting can be changed to tune it to the proper value. 

Example: A game may pause to wait for th e user to make a choice, but then continue if the user does not react. 

Idle Sensitivity 

Function: The idle sensitivity level sets a threshold forjudging when applications are idle. The value is the percentage of the 
maximum possible polling rate that the application can perform. The polling rate is a factor of processor speed, application 
priorities, and the number of tasks that are active in the system. If an application polls at a rate higher than this value, it is 
considered to be idle. 

Idle detection is a “best guess” of what the program is doing. It could be that the program is polling at a very high rate, but is still 
doing useful work between checking. It may be that the application checks at a slow rate, but still is doing nothing but waiting. 

The idle sensitivity threshold allows adjustment of the threshold for a particular application. 

DOS programs often “poll” for input when they are waiting for a user response. For instance, a program may wait for a response 
by repeatedly checking to see if the user has hit a key. In a multitasking environment such as OS/2, this wastes time when other 
programs could be running instead. The operating system detects idle programs by looking for a high rate of polling for input. 
When programs are judged to be waiting for input, they are given less time to run. 

For example, if idle sensitivity is set to 75%, then an application that repeatedly checks whether input is available would have to 
do this checking at more than 75% of the maximum possible polling rate before it would be judged idle. 

(R) 

For some communication applications (such as ProComm Plus ) and full-screen video applications, it is better to set this value 
low, perhaps at 30 rather than 75. Also, tune theTIMESLICE parameter in CONFIG.SYS if system performance is still noticeably 
slow. Start with TIMESLICE=64,128 and tune from there. 

Advantages: If an application receives input while running but seems to run slower than expected, the idle sensitivity should be 
set to a higher value. This lets the application poll at a higher rate without being judged idle. Setting the level to 100 turns idle 
detection off altogether, and the application will be allowed to poll for input as often as it likes. 

If an application is waiting for input and other applications do not appear to be running, the idle sensitivity should be adjusted 
downward. This lowers the threshold for proclaiming the application idle. 

Default: 75%. 

Settable: The setting can be changed while the program is running to tune it to the proper value. 

I0PL Lock 

Function: It enables or disables trapping instructions that affect the interrupt flag. 

Advantages: It resolves problems that can be encountered with certain copy-protected or timing-sensitive applications. 

Drawbacks: It can increase interrupt latency to a potentially unusable level. 

Default: Off. 

Settable: At Virtual DOS Session creation time only. 

Example: FI5, a copy-protected flight simulation game, will not run without this feature. 


Figure 2. Hardware Environment Settings (continued) 
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Keyboard: Buffer Extension 

Function: It increases a Virtual DOS Session’s keyboard type-ahead buffer size. 

Advantages: It provides greater keystroke buffering, consistent with the level available in Virtual Input/Output (VIO) windows. 
Note that Ctrl-Break flushes the entire buffer, just as it does with the standard buffer. 

Drawbacks: Applications that bypass the ROM BIOS input buffer or INT 16h may not benefit from this feature. There also is a 
small amount of additional memory overhead for every Virtual DOS Session. 

Default: On. Most applications will benefit, and those that do not should not be adversely affected. 

Settable: At any time. This facilitates easy experimentation by the user in the rare event that a problem arises. 

Timer Hardware Access 

Function: This setting allows direct access to the 8253 timer ports. 

Advantages: Certain timing-critical applications will not run, or will run much slower, if accesses to timer ports are trapped and 
virtualized (that is, if applications access a virtual timer instead of the hardware timer). In addition, the values they read do not 
accurately reflect the amount of time that has passed, because they do not take trapping overhead into account. Enabling this 
setting allows certain timing-dependent code to run more effectively. 

Drawbacks: Applications that change the divisor before this setting is enabled, then read the timer ports after the setting has been 
enabled, may not function properly. If the setting is enabled first, the Virtual DOS Session cannot correctly detect changes to the 
divisor, and the simulated interrupt frequency will be incorrect. Multiple applications using this setting can interfere with one 
another. 

Default: Off. Most applications will operate normally with a virtual timer. 

Settable: At any time. It is useful to alter this setting dynamically and to watch for changes in application performance. 

Example: The ROM on some computers implements very brief delays by polling the timer ports. These delays become 
unacceptably long unless direct timer port access is allowed. 


Figure 2. Hardware Environment Settings 


DOS Device Drivers 

Function: This setting can be used to add or modify information about DOS device drivers, in addition to the information 
specified in CONFIG.SYS. Do not specify device drivers that applications do not use, because each loaded driver takes space from 
DOS applications that run in this session. 

Default: When this setting is selected, a list is displayed that contains information about each DOS device driver specified in 
CONFIG.SYS. This information consists of the path and file name of each DOS device driver and its current parameters, if 
applicable. An example of this information is as follows: 

c:\os2\mdos\ansi.sys 

The user can: 

• Type (as the value of this setting) the name of a DOS device driver to add it. Typing should begin on a new line. 

• Delete all the information about a device driver to remove it. 

• Type additions, changes, or deletions to a value. 

Settable: At Virtual DOS Session creation only. 

DOS Memory Size 

Function: This setting specifies the DOS memory size in KB. This is the amount of memory available to DOS applications. 
Advantages: The virtual video device driver uses this setting on certain video adapters to set more than 640 KB. 

Drawbacks: This setting is insignificant to most users because there is no reason to specify less than 640 KB. 

Figure 3. DOS Environment Settings (continued) 
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Default: 640 KB. 

Settable: At Virtual DOS Session creation only. 

Last Drive 

Function: This setting specifies the highest disk drive letter accessible to the DOS session. 

Advantages: Restricting the highest disk drive letter saves a small amount of standard memory in the DOS session. 
Drawbacks: The DOS session is restricted to drive letters less than or equal to the last drive specified. 

Default: Z. 

Settable: At Virtual DOS Session creation only. 

Memory: Load DOS High 

Function: This setting specifies that DOS be loaded in the High Memory Area (HMA) if set on. 

Advantages: It adds more than 40 KB to the standard memory area available to DOS application programs. 
Drawbacks: Some DOS programs require that DOS be loaded low. 

Default: On. 

Settable: At Virtual DOS Session creation only. 

Figure 3. DOS Environment Settings 


Memory: DPMI 

Function: This setting defines the maximum amount of DPMI memory available to all applications running in this DOS session. 
The field for this setting contains values expressed in 1 MB intervals ranging from 0 to 512 MB. Select 0 if the applications to be 
run in this session do not require DPMI. 

Advantages: DPMI allows applications to run in protected mode, which allows application programs to address more than the 1 
MB of memory available in real mode, the standard mode used by DOS applications. DPMI is required to run Windows 
applications in their standard mode. The application’s documentation should indicate if the application can take advantage of 
DPMI memory. 

Drawbacks: Specifying DPMI memory for a DOS session incurs only a small amount of overhead if the memory is not used. 
Specifying excessive values of DPMI for many DOS sessions could result in exhaustion of system swap space. 

Default: 3 (MB). 

Settable: At Virtual DOS Session creation time only. 

Memory: EMS Frame Location 

Function: The Lotus -Intel-Microsoft Extended Memory Specification (LIM EMS) uses a 64 KB address region, called an EMS 
page frame, through which programs access expanded memory. This enables programs to use more than 640 KB of memory. 

Advantages: If there is a problem running a program that uses both a hardware device and LIM EMS expanded memory, it may 
be due to conflicting use of addresses by LIM EMS and the hardware device. If so, the EMS Frame Location setting should be 
changed to specify the extra address region used by EMS as 0. If the problem persists, the EMS Frame Location setting can be 
used to select a 64 KB region that does not conflict with hardware. 

The frame location can be selected from a list of choices or the EMS frame can be omitted for programs that do not require a 
frame. Also, the DOS memory size setting can be reduced and the frame placed below 640 KB. 

Drawbacks: Rather than using this setting, the best solution for problems due to hardware address conflicts is to use the other 
Exclude Regions and Include Regions settings to specify the addresses that the hardware uses. Care must be taken when using 
these settings, because detailed knowledge of your computer’s hardware address usage is required. 

Default: The default setting, AUTO, leads to correct choices of LIM EMS addresses. Most users will never need to change this 
setting. 


Figure 4. Memory Extender Settings (continued) 
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Settable: At Virtual DOS Session creation time only. 

Example: In some cases, the default choice may conflict with addresses used by the computer’s hardware. This can happen only 
for devices that are not supported by a virtual device driver. 

Memory: EMS High OS Map Region 

Function: In addition to the EMS page frame, some programs can use additional addresses to access expanded memory. This 
setting allows advanced users to adjust the size of the additional EMS region. 

Advantages: Advanced users can use other Exclude Regions and Include Regions settings to specify the addresses used by 
devices that do not have virtual device drivers, and can then set the size of the high OS region appropriately for their programs. 
Care must be taken to ensure that the hardware addresses do not conflict with other addresses being used within OS/2. 

Default: The value set is the size of the region in KB. The default is 32 (KB). 

Settable: At Virtual DOS Session creation only. 

Memory: EMS Low OS Map Region 

Function: Some programs can use remappable conventional (RAM) memory. This setting allows advanced users to set the size of 
the remappable conventional memory available in a Virtual DOS Session. 

Default: The value set is the size of the region in KB. The default is 384 (KB). 

Settable: At Virtual DOS Session creation only. 

Memory: EMS Memory Size 

Function: This setting controls the amount of EMS memory available to a Virtual DOS Session. 

Advantages: The user can set this to a higher value for running programs that require a large amount of EMS. Other programs do 
not use EMS at all. To disable EMS support in such cases, the size can be set to 0 for that Virtual DOS Session. Programs 
generally state whether they use EMS on the product box or in their manuals. 

Default: The value set is the size of the region in KB. The default size is 4 (KB). 

Settable: At Virtual DOS Session creation time only. 

^Example: If a spreadsheet runs out of memory, the amount of EMS can be increased and the Virtual DOS Session restarted. 

Exclude Regions 

Function: This setting specifies the address ranges that should be protected from use by EMS or XMS and from direct access by 
applications. This setting is intended for experienced users who understand the hardware address ranges that are used in OS/2. If 
an incorrect setting is specified, unpredictable results can occur. 

Advantages: This setting restricts the use of EMS and XMS in certain ranges in the region between Real Memory Size (RMSIZE) 
and 1 MB. It also protects these ranges from being accessed by user applications by portraying ROM in those address ranges. 

Drawbacks: Some hardware adapters stop functioning if their addresses are accessed in random fashion. If these ranges are 
defined excessively, they will adversely impact the function and performance of EMS and XMS services. 

Default: By default, this setting is void (that is, nothing follows the equal sign). Each address is specified in hexadecimal; if no 
range is specified, the length taken is a page (4 KB). 

Settable: At Virtual DOS Session creation only. 

Include Regions 

Function: This setting specifies some address ranges between RMSIZE and 1 MB for use by EMS and XMS. 

Advantages: If the user knows that there is a hardware adapter in this range that is not going to be used by a particular Virtual 
DOS Session, then the address range used by this adapter should be made available to EMS and XMS. This will improve the 
performance of EMS and XMS services. Only advanced users who know the addresses used by an adapter card should use this 
setting. 

Default: By default, this setting is void. 

Settable: At Virtual DOS Session creation only. 

Figure 4. Memory Extender Settings (continued) 
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Memory: DOS Owns Upper Memory Blocks (UMBs) 

Function: The use of Upper Memory Block (UMB) areas allows certain types of DOS code, such as Terminate-and-Stay-Resident 
(TSR) programs and DOS device drivers, to be loaded into memory addresses between 640 KB and 1,024 KB. This frees memory 
in the 0 to 640 KB range for application use. 

The DOSEM kernel owns and manages all UMB areas. Code is then loaded into UMB areas by the DEVICEHIGH and LOADHIGH 
commands. However, if an application program needs to manage UMB areas, the DOS emulation kernel must relinquish owner¬ 
ship and management of this memory. This can be done for individual Virtual DOS Sessions that turn off the DOS-owned UMB 
setting. 

DOS ownership of UMB areas can be enabled or disabled for all Virtual DOS Sessions by including either D0S=UMB or 
D0S=N0UMB in CONFIG.SYS. 

Default: By default, D0S=UMB (DOS owns UMB) is in effect (On). 

Settable: At Virtual DOS Session creation only. 

Memory: (Number of) XMS Handles 

Function: This setting specifies the number of XMS Extended Memory Block (EMB) handles. A handle is used with each EMB. 
This number is required because XMS preallocates all the handle space to be compatible with XMS specifications. This setting 
should be used only if an application uses a large number of handles. 

Advantages: This setting restricts the number of block handles, thereby reducing memory consumption. 

Drawbacks: Specifying a large number of handles increases memory consumption and adversely impacts system performance. 
Default: The default value is 32. 

Settable: At Virtual DOS Session creation only. 

Memory: XMS Memory Limit 

Function: This setting specifies the global and individual Virtual DOS Session XMS memory limits. Use this setting under the 
same guidelines as described in the preceding section on XMS Handles. The global limit is the overall maximum XMS memory 
consumption, and the individual Virtual DOS Session limit is the maximum allowed for each session. 

Drawbacks: Specifying a large number may adversely affect system performance. 

Default: The default value is 2048 (KB) for an individual Virtual DOS Session. 

Settable: At Virtual DOS Session creation only. 

Example: The setting 8192,4096 specifies 8 MB for the overall limit and 4 MB for each Virtual DOS Session. 

Memory: XMS Minimum Usage of High Memory Area (HMA) 

Function: This setting specifies the minimum HMA memory request allowed. This setting lets the user fine-tune the XMS. HMA 
is slightly less than 64 KB in size. Only one request at a time can be fulfilled from this area, and only a real-mode application can 
use this memory as conventional memory. 

Advantages: If a TSR takes a very small allocation, it will waste this area for other applications. In such cases, a limit can be 
specified. 

Default: The default value is zero, which means that all requests will be allowed. 

Settable: At Virtual DOS Session creation only. 

Example: The 2048 sets a limit of 2 KB. 

XMS UMB Deactivation 

Function: UMBs are the regions anywhere between RMSIZE and 1 MB where the memory is available to XMS. All the regions 
specified in other Include Regions are available here. 

Advantages: When this setting is enabled, XMS waits for the first UMB request before allocating all UMBs. This is done to give 
UMBs better hardware support. 

Default: By default, UMBs are not supported to minimize conflict with adapters; however, if an application depends on UMBs, 
this setting should be enabled. 

Settable: At Virtual DOS Session creation only. 

Figure 4. Memory Extender Settings (continued) 
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FCB Count 

Function: This setting specifies the maximum number of File Control Blocks 
(FCBs) that can be opened. This setting has no effect unless a file-sharing module is 
loaded. 

Advantages: In a networking environment, the performance of a Virtual DOS 
Session can be severely impacted if a large number of FCBs are active. Through this 
setting, the user can specify a limit to such file openings. If the open count crosses 
this limit, DOS closes the least recently used FCB. 

Default: The default value is 16. 

Settable: At Virtual DOS Session creation only. 

FCB Count, No Close 

Function: This setting specifies the number of FCBs that will be protected against 
automatic closure. 

Advantages: If this setting is specified as a number /?, the first n files are protected 
against automatic closure as described in the previous setting. 

Default: The default value is 8. 

Settable: At Virtual DOS Session creation only. 


Figure 5. File Operation Settings 


Video: Window Refresh 

Function: This setting adjusts the window update frequency (in seconds) for a given 
Virtual DOS Session. 

Advantages: For applications (particularly graphics) that write frequently to video 
memory, this value can be increased to reduce the time spent updating the window 
and to provide more processor time for the application. This setting has no effect on 
updates based on other events such as keyboard input or synchronous scrolling 
operations. 

Drawbacks: A large refresh period can make an application unusable or very hard 
to use. 

Default: The default value is 0.1 (seconds). This value has been found to yield the 
best overall performance. 

Settable: At any time, in increments of 0.1 seconds. The range is from 0.1 to 60.0 
seconds. 

Example: This setting affects normal TTY-style output. Compare a DIR or TYPE 
operation before and after altering this setting. 

Video: Window Scroll Synchronization 

Function: This setting skips window updates on individual scroll operations. 

Advantages: Scrolling in a window is several times faster. Use this setting in 
conjunction with Window Refresh to obtain a desirable refresh rate. 

Drawbacks: Scrolling is not as smooth as full-screen operation. 

Default: On. In most cases, smooth scrolling will be more important to users than 
very fast scrolling. 

Settable: At any time. This permits experimentation. 

Example: This setting affects normal TTY-style output. Compare a DIR or TYPE 
operation before and after altering this setting. 


to close and release all resources 
when they are no longer needed. This 
includes files, windows, dialogs, and 
memory. Remember that with the flat 
memory model, all variables are 32 
bits in length. Take advantage of the 
32 bits for flags and addresses. Also, 
be sure to align the code and data on 
32-bit boundaries to optimize 
memory accesses. 
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Figure 6. Windowing Settings 
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Cleaner Installation of 
Applications Under OS/2 

Claude Goffin 
IBM Corporation 
La Hulpe, Belgium 

Installing , customizing , and maintaining OS/2 applications can be com¬ 
plex and time-consuming , because some application installation proce¬ 
dures add new directories to the hard disk and modify the operating 
system's CONFIG.SYS file. This article presents some tips for installing 
and accessing applications more cleanly , without changing the 
CONFIG.SYS file each time a new? application is added. 


E very session running under 
OS/2 has its own environment, 
and each session’s environment 
can be modified. The environment of 
an OS/2 session is a special area in 
storage that contains information 
specific to that OS/2 session. That 
information consists of the subjects 
discussed in this article: system vari¬ 
ables, user variables, the current 
drive, and the current directory for 
every accessed drive. Accessed 
drives consist of all the physical and 
logical drives defined in the OS/2 
installation; a local virtual disk, 
defined by the parameter 
DEVICE^C:\0S2\VDISK.SYS in 
CONFIG.SYS; or a remote virtual disk 
residing on a Local Area Network 
(LAN) server. The entries in the 
CONFIG.SYS file define the default 
environment of all OS/2 sessions 
running concurrently. 

Most application vendors recom¬ 
mend modifying CONFIG.SYS to 
include their specific requirements. 
The advantage of modifying 
CONFIG.SYS is that an application 
can then be used by any session. But 
there also are adverse effects. The 
chain of directories to be searched 
for a specific file is long. The 
CONFIG.SYS file becomes unwieldy. 
Worse, even after users remove an 


application from their computers, 
they rarely remove the command 
lines in the CONFIG.SYS file that 
were added when the application was 
installed. Finally, application vendors 
have many different methods of 
modifying CONFIG.SYS, and these 
differences confuse users. These 
situations can lead to difficulties in 
customizing, maintaining, and debug¬ 
ging a system. It also can cause loss 
of data files. 

Sometimes a new program does not 
meet expectations, and it is removed 
from the system. Because of this 
possibility, it is strongly advised that 
you make a copy of the existing 
CONFIG.SYS file before installing 
any new program. Some programs 
attempt to do this for you by renam¬ 
ing the existing CONFIG.SYS file to 
CONFIG. BAK or a similar name. 
However, this can lead to a conflict 
if you already have a CONFIG. BAK 
and you are now installing a program 
that wants to create a different 
CONFIG. BAK. Here is a suggestion: 
Each time you install a new applica¬ 
tion, save the most recent CONFIG.SYS 
file under the name CONFIG. NNN 
(where NNN can be a Julian date or a 
simple sequential number), and store 
CONFIG. NNN in a directory of backups 
-such as D:\BACKUP\CONFIG.NNN. 


Because of all the drawbacks of 
modifying CONFIG.SYS, an applica¬ 
tion installation strategy can mini¬ 
mize changes to CONFIG.SYS and 
make installation and maintenance 
significantly easier. The installation 
strategy discussed in this article takes 
advantage of OS/2. The purposes of 
this article are to explain this ap¬ 
proach and to help users and techni¬ 
cal support personnel develop their 
own installation strategies. 

The next four sections discuss the 
concepts of the OS/2 session environ¬ 
ment, user and system variables, sys¬ 
tem search sequences, and Dynamic 
Link Libraries (DLL). If you are 
familiar with these concepts, you 
may wish to skip to the section 
“General Guidelines.” 

User and System Variables 

Because OS/2 is a multitasking oper¬ 
ating system, it allows concurrent 
occurrences of multiple OS/2 ses¬ 
sions in which batch files (. CMD) or 
applications are executed. It is impor¬ 
tant to keep in mind that every OS/2 
session has its own environment. 

System variables are defined by using 
SET commands in CONFIG.SYS. This 
article covers the following system 
variables: 

• PATH specifies the search path for 
executable files (.CMD, .COM, 

.EXE). 

• DPATH specifies the search path for 
data files. 

• HELP specifies the search path for 
help files (.HLP). 

• BOOKSHELF specifies the search 
path for information files (.INF). 

User variables are created and 
defined by using SET commands that 
are issued at the OS/2 system prompt 
or in a batch file. User variables are 
the replaceable parameters in batch 
(. CMD) files. Here is an example of 
their usage. 
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Suppose CHECK. EXE is a program 
that checks and corrects the file 
D: \W0RKING. DAT. This file is a tem¬ 
porary workspace into which other 
“original” files are copied, then 
CHECKed, then copied back. 

Assume one of these original files is 
D:\USER\WORK\BALANCE.DAT. To 
CHECK this file in an OS/2 session, 
you might use these commands: 

COPY D:\USER\WORK\BALANCE.DAT 
D:\WORKING.DAT 
CHECK 

COPY D:\WORKING.DAT 

D:\USER\WORK\BALANCE.DAT 

To CHECK another original file, it 
is necessary to use another set of 
these commands with a different 
file name substituted for 
D:\USER\WORK\BALANCE.DAT. 
Clearly, this can get tedious if you 
want to CHECK many files. 

There is an easier way to accomplish 
this. Use the SET command to define 
and fill a user variable with the name 
of the original file. In the above 
example, the commands for defining 
and filling a user variable MY DATA are 
as follows: 

SET MYDATA-D:\USER\WORK\BALANCE.DAT 
COPY %MYDATA% D:\WORKING.DAT 
CHECK 

COPY D:\WORKING.DAT %MYDATA% 

The file name 

D:\USER\WORK\BALANCE.DAT is sub¬ 
stituted for the user variable MY DATA. 
In the COPY statements, the percent 
signs on both sides of the name 
MY DATA indicate that MY DATA is a user 
variable that is replaced by an actual 
value (in this case, a file name) 
before execution. 

Next, create a batch file DO. CMD that 
contains the last three commands 
shown above: 

COPY %MYDATA% D:\WORKING.DAT 
CHECK 

COPY D:\WORKING.DAT %MYDATA% 


The combination of the user variable 
MY DATA and the batch file DO. CMD 
can now be used to CHECK several 
files: 

SET MYDATA-D:\USER\WORK\BALANCE.DAT 
DO 

SET MYDATA-D:\USER\WORK\ASSETS.DAT 
DO 

SET MYDATA-D:\USER\WORK\BILLS.DAT 
DO 


The SET command also can be used 
in a batch file. In this case, however, 
you must edit that batch file each 
time you want to modify the value of 
one user variable. 

System variables also can be used as 
replaceable parameters. The system 
variables %PATH%, %DPATH%, %HELP%, 
and %B00KSHELF% can be used in 
commands and batch files. You can 
then assign actual values to these 
variables with the SET command; for 
example: 

SET PATH=D:\UTIL 

The current values of all user and 
system variables in an individual 
OS/2 session can be seen any time by 
typing the command SET. 

Changing System Variables 

Within a single OS/2 session, the 
values assigned to user and system 
variables in SET statements are valid 
only for that session. No other ses¬ 
sions are affected. Often, however, 
the system variables must have 
default values in all concurrent 
OS/2 sessions. This is where the 
CONFIG.SYS file becomes important. 
Every time the system is powered on, 
OS/2 searches the root directory of 
the drive where it started (usually the 
C: drive) for the CONFIG.SYS file. 
The CONFIG. SYS file is a batch file 
that OS/2 interprets to assign values 
to variables and set up the system 
according to the devices that are at¬ 
tached. OS/2 performs these proce¬ 


dures before it permits individual ses¬ 
sions to start. 

In OS/2, one purpose of CONFIG.SYS 
is to provide every OS/2 session with 
a default set of variables. The default 
variables for all sessions are defined 
by using SET commands in the 
CONFIG.SYS file. 

At system boot time, CONFIG.SYS 
defines a default set of system vari¬ 
ables, and eventually user variables. 
To make a permanent change, you 
must edit the CONFIG.SYS file, then 
reboot the system. To change a vari¬ 
able temporarily in an individual 
OS/2 session, either rewrite the SET 
statement or add new parameters to 
it. Two examples follow. 

To replace the path defined in 
CONFIG.SYS with a new one: 

SET PATH=D:\USER\APPS; 

To add this same new entry to the 
beginning of the current path: 

SET PATH«D:\USER\APPS;%PATH% 

Note : You can use the commands 
PATH and DPATH instead of SET either 
on the command line or in a batch 
file, but not in CONFIG.SYS. How¬ 
ever, for simplicity, this article uses 
only the SET command. 

Current Directories and 
Search Sequences 

Each OS/2 session has its own cur¬ 
rent directories, as shown in the fol¬ 
lowing example. Suppose you are 
using two drives, C: and D:. In a 
single OS/2 session, you issue the 
following commands: 

C: 

CD C:\DIRC 
D: 

CD D:\DIRD 
PROG 

Notice that the second line includes 
the full path (C:\DIRC), not just 
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\DIRC or DIRC. (The OS/2 2.0 
Command Reference manual has 
examples that useXDIRC or DIRC. 
These examples are correct, but they 
do not consider the pitfall explained 
here.) It is safer to include the full 
path, especially when you are run¬ 
ning a batch file. For example, if you 
had previously issued the command 
CD \W0RK, then the command CD 
DIRC would make C:\WORK\DIRC 
(if it exists) the new current directory. 
If C:\WORK\DIRC does not exist, the 
session will abruptly stop when it 
tries to find this non-existent file later. 

At the point of invoking PROG: 

• The current directory of the C : 
drive is C:\DIRC. 

• The current directory of the D: 
drive is D: \ DIRD. 

• The current directory of the ses¬ 
sion is also D:\DIRD. 

PROG is the name of the executable 
file (.EXE, .COM, or . CMD) to be run. 
When OS/2 searches for executable 
files to run in an individual session, it 
checks the last SET PATH= statement 
issued during that session. If no SET 
PATH= statement has been issued, 

OS/2 then checks the SET PATH* 
statement in CONFIG.SYS. 

In OS/2, the dot (.) can be used in 
SET PATH* statements to indicate the 
current directory. For example, sup¬ 
pose that in the OS/2 session, you 
issue the statements: 

SET PATH*.\UTIL;C:.;%PATH% 

C: 

CD C:\DIRC 
D: 

CD D:\DIRD 
PROG 

OS/2 then searches for the executable 
file PROG in the following order: 

1. Current directory of the session 
(D:\DI RD) (If the needed file is 
not found in the current directory, 
the search is done as defined in the 


PATH system environment 
variable.) 

2. Subdirectory \ UTIL of the current 
directory, if it exists 
(D:\DIRD\UTIL) 

3. Current directory of drive C: 
(C:\DIRC) 

4. Directories in the previous value 
of the PATH variable for that ses¬ 
sion (This is generally the value 
that was set in the SET PATH* 
statement in CONFIG.SYS.) 

Using the dot also is valid in the 
following statements: 

• SET DPATH* establishes the search 
path for data files. 

• SET HELP* establishes the search 
path for help files (. H L P). 

• SET BOOKSHELF* establishes the 
search path for documentation 
files (.INF). 

Dynamic Link Libraries 

All running OS/2 sessions can share 
Dynamic Link Libraries (.DLL) files. 
The .DLL files are loaded into 
memory when needed. At runtime, 
an application may need routines 
stored in .DLL libraries, so the appli¬ 
cation must know the path for find¬ 
ing the .DLL files. This is the reason 
for the LIBPATH* command in 
CONFIG.SYS. (The LIBPATH is not 
part of the environment of an indi¬ 
vidual OS/2 session; it applies to all 
concurrent OS/2 sessions, so it can¬ 
not be defined using a SET com¬ 
mand.) DLLs common to multiple 
applications should be put into a 
single directory that is specified in 
the LIBPATH* statement. 

There is no naming convention for 
DLLs. Eventually, identical names 
for .DLL files will appear in different 
applications. It may be helpful to 
group the DLLs specific to one appli¬ 
cation with the other files for that ap¬ 
plication. That is what many program 
installation procedures do. Although 


it is not necessary, the installation 
procedures also want to update the 
LIBPATH* statement in CONFIG.SYS 
to point to their particular applica¬ 
tions. Doing this has some negative 
effects: 

• The LIBPATH-statement becomes 
cluttered - too long and difficult to 
read. 

• The search sequence for the 
needed file is long. 

• Identical DLL names in different 
applications can cause a search to 
locate the wrong .DLL file. 

• This arrangement is not well 
suited to a LAN environment 
where applications reside on a 
server. 

• When one wants to remove an ap¬ 
plication, and therefore the DLLs 
belonging to it, there is almost no 
way to know which DLLs to 
remove. 

When an OS/2 session searches for 
DLL files, it does not search the cur¬ 
rent directory of that OS/2 session 
first. Instead, the search sequence is 
the one specified in the LIBPATH- 
statement; this search sequence is the 
same for all concurrent OS/2 sessions. 

Therefore, when program installation 
procedures modify - in fact, lengthen 
-the LIBPATH* statement in 
CONFIG.SYS, each OS/2 session has 
to search unnecessarily through all 
.DLL files, not just the ones it needs. 

Fortunately, the dot feature provides 
an alternative for searching for 
DLLs. Here is how it works. Assume 
the LIBPATH* statement in the 
CONFIG.SYS file is as follows: 

LIBPATH*.;C:\0S2\DLL; 
C:\MUGLIB\DLL; ... 

In this example, the dot follows the 
equal sign. This dot represents the 
current directory of an individual 
OS/2 session. Therefore, although the 
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value of LIBPATH will be the same 
for every OS/2 session, the value that 
replaces the dot will be different for 
each session. Here is a practical 
example of using the dot instead of 
modifying the LIBPATH- statement 
in CONFIG.SYS. 

Suppose you are installing a program 
called ALONE, and its installation 
process modifies the LIBPATH- 
statement above to look like this (all 
in one line): 

LIBPATH-C:\AL0NE;C:\0S2\DLL;C: 
\MUGLIB\DLL; (rest of the 
statement) 

This permanently changes the 
LIBPATH. Every OS/2 session that 
needs DLL files will look for them 
in the ALONE directory first, even 
though the DLL files in the ALONE 
directory apply only to the session 
that is running the ALONE program. 

A better alternative is to start the 
LIBPATH- statement with a dot, as 
shown above. Then issue the follow¬ 
ing statements to start the ALONE 
program: 

C: 

CD C:\AL0NE 
ALONE 

The term C:\AL0NE will be substi¬ 
tuted where the dot is. As a result, for 
the ALONE session only , the LIBPATH 
will behave as though it begins with 
C:\AL0NE. 

Now suppose that in another OS/2 
session you want to execute a pro¬ 
gram called NEXTPROG, and that the 
program and its DLLs reside in 
D:\NEXTPROG. The following state¬ 
ments will execute NEXTPROG, and 
the search for DLLs will begin in the 
D:\NEXTPROG directory for this 
session only : 

D: 

CD D:\NEXTPROG 
NEXTPROG 


General Guidelines 

It is now time to use the concepts 
learned thus far. The rest of this ar¬ 
ticle gives guidelines for establishing 
and adhering to an installation and 
maintenance strategy that facilitates 
application installation, system main¬ 
tenance and backup, and saves debug¬ 
ging time. 

OS/2 System Files 

The C: drive, whether physical or 
logical, should be reserved for OS/2 
system files. When all OS/2 system 
files are in one place and are isolated, 
it becomes much easier to upgrade 
some or all of those files. They can 
be upgraded from diskettes, internal 
or external tape drives, a PS/2-to- 
PS/2 connection, or through a connec¬ 
tion to a LAN server or to a host 
computer. Before upgrading, be sure 
to back up CONFIG. SYS, all .INI 
files, and the STARTUP. CMD file (if 
this file is installed). 

There is another big advantage of put¬ 
ting all system files onto one drive. If 
there is more than one operating sys¬ 
tem on your computer, the files of 
each operating system can go onto 
their own drive. You can then run the 
applications (which are on a separate 


drive) from each of those operating 
systems. 

Application Files 

With few exceptions, each applica¬ 
tion should have its own directory or 
subdirectory for placing all files from 
the application package. Again, the 
obvious advantage is that it then be¬ 
comes simple to install a new version 
of that application. There are some 
exceptions: 

• Some tools consist only of DLLs. 
A well-known example is REXX 
extensions, which can be used by 
several programs. Those DLLs are 
good candidates for placing into a 
common DLL directory referred to 
in the LIBPATH- statement. 

• Some tools consist of only one 
.EXE file. These tools are used in 
any session through the command 
line or in another .CMD. They are 
good candidates to place into a 
common utility directory referred 
to in the SET PATH- statement. 

Personal Files 

Personal files consist of data files and 
control files. Datafiles are texts, 
spreadsheets, and so on. They can be 
grouped according to the applications 
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that access them; most data files are 
accessed by only one application. 
Control files usually contain param¬ 
eters that can be customized for an 
application. These files are typically 
named Profile (. PRO) or Configura¬ 
tion (. CGF); they also can be cus¬ 
tomizable batch files. Personal files 
contain information such as the name 
of the directory for storing temporary 
and final results; autosave intervals; 
alarms; names of diaries; programmed 
keystrokes; color and sound preferen¬ 
ces; and personal dictionaries for 
spell-checking and proofreading. 

As with system and application files, 
it is best to put related personal files 


into their own separate directory or 
subdirectory. 

Most application packages contain 
default control files that can be 
changed based on needs. To do this, 
copy each application’s default con¬ 
trol files into a personal directory or 
subdirectory so you can edit those 
personal control files. Then, if you 
install a new version of the applica¬ 
tion, the personal control files will 
not be overwritten because they are 
in another directory. 

CONFIG.SYS 

Statements in CONFIG.SYS should be 
as short and stable as possible. Apply¬ 


ing the strategies in this article 
should remove the need to modify 
CONFIG.SYS. 

Starting Applications 

To set up the environment of an OS/2 
session in which an application will 
run, use batch (. CMD) files. Every 
application can be started with a 
. CMD file. This starting batch file can 
be executed from an OS/2 system 
prompt or by double-clicking on the 
“Starting Application” icon. When 
creating the corresponding program 
object, this . CMD file is the one to 
specify in the path and file name of 
the Program tab in the Settings 
notebook. The starting batch file also 
is a good candidate to put into the 
common utility directory referred to 
in the SET PATH= statement in 
CONFIG.SYS. 

The .CMD file that starts the applica¬ 
tion has the following structure: 

1. Define current directories for the 
accessed drives and for the OS/2 
session 

2. SET the variables for the applica¬ 
tion (if any) 

3. applexe 

4. EXIT 

The starting batch file sets up the 
environment for the desired applica¬ 
tion, and then starts that application. 

Appl exe is a generic term for an exe¬ 
cutable file that runs an application; 
for example, the actual executable 
file might be D:\ALONE\ALONE.EXE 
(it is good practice to use the full 
path). 

After double-clicking on the “Start¬ 
ing Application” icon, it appears gray 
(or cross-hatched) indicating that the 
application has been started. In the 
course of your work, you will have 
minimized the application window. 
Double-clicking again on the “Start- 
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DLL' 





UTIL 2 





applname PACKAGE 3 
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applname PACKAGE 


FONTS 5 
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Notes: 

1 D:\DLL stores DLLs common to all applications. 

2 D:\UTIL stores all executable files of tools (except those that came with the OS/2 
system). It also is the place to store all the starting batch files that are created. 

3 D:\appl name\ PACKAGE stores all original files that came with the appl name appli¬ 
cation (.EXE, .DLL, .INF, .HLP, and so on). 

4 D:\applname stores all personal files related to the appl name application. It is not 
always obvious which files to copy from D:\appl name\PACKAGE to D:\appl name. 
When you can modify an application’s settings, it is good to check which files have 
changed, to copy those files into the D: \appl name directory, and then to restore the 
original files from the application package. 

5 Some applications also create subdirectories. Generally, these subdirectories do not 
affect the installation strategy. 

Figure 1. Directory Tree for a Single Drive 
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ing Application” icon restores the 
application window to its normal size. 

An OS/2 window icon related to the 
starting batch file is created in the 
minimized Window Viewer. This is 
useful while testing, but you may 
keep it from being created by select¬ 
ing “Hide Window” in the Window 
tab of the Settings notebook. 

Not all applications require a starting 
batch file because the options avail¬ 
able in the Settings notebook are suf¬ 
ficient. However, there is little or no 
inconvenience in using this approach, 
and experience shows that users who 
adopt this approach never encounter 
problems. 

Proposed Strategies 

It is now time to apply the guidelines 
to specific strategies. This section dis¬ 


cusses installation and maintenance 
strategies for two scenarios: running 
applications using a single drive and 
running applications using two drives. 
Each scenario includes a suggested 
directory tree layout, a modified start¬ 
ing batch file, and a modified 
CONFIG.SYS file. 

Running Applications on a 
Single Drive 

Running applications on one drive 
(D:) in addition to the operating sys¬ 
tem drive (C:) makes disk space 
management easy and works well in 
most cases. The suggested directory 
tree is shown in Figure 1. 

For each application applname, 
create the starting batch file 
D:\UTIL\applname.CMD, as shown 
in Figure 2. 


Next, edit the CONFIG. SYS file only 
once, as shown in Figure 3, so that it 
reflects the suggested directory tree. 

If you have only one disk drive (C:) 
for both OS/2 and applications, put 
your applications into C: \APPS, and 
substitute C: \ APPS\ where you see 
D: \ in the above examples. 

Running Applications Using 
Two Drives 

Two drives may be necessary in 
some circumstances, such as a LAN 
environment. Assume drives D: and 
E: are used for applications. The sug¬ 
gested directory trees are shown in 
Figure 4. 


D: DLL 

E: 


UTIL 


applname'^ 


applname 



P - 

applname 2 



applname 



P 


Notes: 

1 D:\applname stores all personal files, 
including customized control files, 
related to the appl name application. 

2 E:\appl name stores all original files 
that came with the appl name applica¬ 
tion (.EXE, .DLL, .INF, .HLP, and so 
on). 

Figure 4. Directory Trees for Two 
Application Drives 


D: 

CD D:\applname 

SET the variables for the application (if any) 

D:\appl name\PACKAGE\APPLEXE (assuming APPLEXE is the program to start) 
EXIT 


Figure 2. Starting Batch File for a Single Drive 


LIBPATH-.;.\PACKAGE;D:\DLL;C:\0S2\DLL;. .. U2 
SET PATH-.\PACKAGE;D:\UTIL;C:\0S2\;... 3 
SET DPATH-.\PACKAGE;C:\0S2;... 3 
SET HELP-.\PACKAGE;C:\0S2\HELP; 

SET BOOKSHELF-.\PACKAGE:C:\0S2\B00K; 


Notes: 

1 The . ; at the beginning of the LIBPATH is not needed, because the DLLs are in 
D: \appl name\ PACKAGE rather than in the current directory (D: \appl name) of the 
session. 

However, you should not remove the . ; that OS/2 2.0 has included, because some 
applications may run from their own directories, or because you may be testing a new 
application for which the starting batch file has not yet been created. 

2 For this OS/2 session, D:\appl nameXPACKAGE will be searched for DLLs first. 
There will be no unnecessary search for DLLs in other directories, and minimal risk of 
encountering DLLs with identical names. 

3 For the PATH and DPATH, the current directory will be searched first, before 

D: \appl nameXPACKAGE. If the control files were copied into D:\appl name (the 
current directory), the customized control files are accessed first, and the default con¬ 
trol tiles (which have the same names) in D:\app1 n a me X PACKAGE are not accessed. 

Figure 3. CONFIG.SYS File for a Single Drive 
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E: 

CD E:\applname 
D: 

CD D:\app1name 

SET the variables for the application (if any) 

E:\applname\APPLEXE 

EXIT 


Figure 5. Starting Batch File Where Applications Reside on Two Drives 


LIBPATH=.;E:.;D:\DLL;C:\OS2\DLL;... 1 
SET PATH=E:.;D:\UTIL;C:\OS2; . . . 2 
SET DPATH-E:.;C:\OS2;.. . 2 
SET HELP-E:.:C:\OS2\HELP; 

SET B00KSHELF=E:.;C:\0S2\B00K; 


Notes: 

The explanation following Figure 3 (the CONFIG.SYS file for a single drive) also 
applies to Figure 6. However, in Figure 6: 

1 An application that is running in an individual session will first search for its DLLs 
in the E:\applname directory before proceeding to search the other DLL directories 
in the LIBPATH= statement. 

2 In the SET PATH= and SET DPATH= statements, the current directory D:\appl name 
that stores the customized control files will be searched before the directory containing 
the files from the original application, E:\applname. 

Figure 6. CONFIG.SYS File for Two Drives 


C: 

CD C:\APPS\applname 
D: 

CD DNapplname 

SET the variables for the application (if any) 

C:\APPS\applname\APPLEXE 

EXIT 


Figure 7. Starting Batch File Where Data Files Reside on One Drive 


Figure 5 shows how to create the 
starting batch file 
D:\UTIL\applname.CMD for each 
application. 

Next, edit the C 0 N FIG. S Y S file only 
once, as shown in Figure 6, so that it 
reflects the suggested directory trees. 

If there is only one additional physical 
drive (D:), and you want to separate 
the data files from the application 
files, put the applications into 
C:\APPS. But you must change the 
starting batch files and CONFIG.SYS 
file. For this situation, Figure 7 
shows the starting batch file and 
Figure 8 shows the CONFIG.SYS file. 


Claude Goff in is an information 
systems consultant in charge of 
PS/2 usability projects in the IBM 
North-West (Europe) organiza¬ 
tion. He joined IBM Belgium in 
1961 in the Scientific Computing 
Centre. He has been a manager 
since 1970 in the areas of systems 
engineering, marketing, installa¬ 
tion support, personal computer 
marketing support, and end-user 
support. Claude also was a senior 
staff member in IBM's European 
Systems Research Institute (IEC), 
concentrating on end-user com¬ 
puting and programmable work¬ 
stations. He has an MS in engi¬ 
neering from the Liege University. 


LIBPATH=.; C:.;D:\DLL;C:\0S2\DLL;... 
SET PATH=C:.;D:\UTIL;C:\0S2;... 

SET DPATH=C:.;C:\0S2;... 

SET HELP-C:.;C:\0S2\HELP; 

SET B00KSHELF=C:.; C:\0S2\B00K; 


Figure 8. CONFIG.SYS File Where Data Files Reside on One Drive 
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Creating Resizable Pushbuttons 

Narsu V. Tatikola 
Computer Aid, Inc. 

Allentown, Pennsylvania 

Resizable pushbutton windows are often created with a special register 
class , but this is difficult to do. This article presents an alternate way to 
create a resizable pushbutton -as a child window of a standard window. 
The article shows each step in building the subclass window procedure 
that creates resizable pushbuttons. 


resentation Manager (PM) 
application programmers often 
say that it is difficult to create a 
resizable window with WC_BUTT0N, 
a pushbutton register class. But you 
also can use WC_BUTT0N to create a 
resizable pushbutton window. Creat¬ 
ing a resizable pushbutton window 
with WC_BUTT0N is not as difficult as 
maintaining the state of the pushbutton 
when the user interacts with it. This 
article shows how to create a pushbut¬ 
ton as a child window of a standard 
window and how to give the window 
all the functionality it needs - resiz¬ 
ing, repainting, and moving the push¬ 
button along with the parent window. 

Creating a Child Window 

The best place to create a child win¬ 
dow - in this case, a pushbutton - is 
within the WM_CREATE message in the 
client window procedure, as shown 
in Figure 1. 

Varying the Pushbutton’s 
Size and Position 

We want to vary the size and position 
of the pushbutton according to the vari¬ 
ations in its parent’s size and posi¬ 
tion. The WM_SIZE message within 
the client window procedure, shown 
in Figure 2, resizes the pushbutton 
according to the size of the client. 

In the call to Wi nSetWi ndowPos, the 
values of xPos and yPos give the 
position of the pushbutton relative to 
the lower left comer of the client. In 


the same call, cXfact and cYfact 
represent the ratio of the sizes of the 
pushbutton and the client area. The 
actual size of the pushbutton can be 
computed dynamically by multiply¬ 
ing the current client size by the cor¬ 
responding ratio factors. 

Giving the Pushbutton a Title 

We want the title of the pushbutton 
to be “OK”, but for now it has been 
deliberately set to null in the 
Wi nCreateWi ndow call. This is 
because we can control only the size 
of the pushbutton and not the size of 
the text in it. The pushbutton can con¬ 
tinue to get smaller, because it is in a 
window whose size can get smaller. 
The text does not get corresponding¬ 
ly smaller, so it is possible that the 
size of the pushbutton will end up 
smaller than the size of its title. 

The simplest way to solve the title 
problem is to subclass the push¬ 
button’s default window procedure 
and trap the WM_PAINT message. A 
good place to do the subclassing is 
within WM_CREATE in the client win¬ 
dow procedure, immediately after the 
Wi nCreateWi ndow call, as shown in 
Figure 3. 

In Figure 3, ButtonCntrl Proc is a 
global variable that holds the address 
of the default window procedure, and 
ButtonWndProc is the subclass win¬ 
dow procedure for the pushbutton. 
(Programming standards often pro¬ 



hibit using global variables. Instead 
of using a global variable for the ad¬ 
dress of the default window proce¬ 
dure, use the window-words of the 
pushbutton to pass the address to the 
subclass window procedure.) 

Preliminary Subclass 
Window Procedure 

We have developed the first pass of 
our subclass window procedure 
ButtonWndProc, as shown in 
Figure 4. 

The subclass window procedure in 
Figure 4 traps the WM_PAINT message 
of the pushbutton and paints the title 
on the pushbutton using any font of 
any size. The subclass procedure 
calls a function Pai ntPushButton 
that gets the size and the handle of 
the pushbutton. With this informa¬ 
tion, it is not difficult even for a 
novice PM programmer to choose a 
corresponding font size and type to 
use for the text. This kind of subclass¬ 
ing works fine for creating a pushbut¬ 
ton with a title, or whenever the 
painting is done again due to resizing 
of the parent window. 

Painting the Pushbutton 

Painting the pushbutton is a tricky 
process, especially when the user 
clicks a mouse on it. When the mouse 
is clicked on the pushbutton, PM 
creates an illusion of the button being 
physically pressed and released. By 
default, the pushbutton is always in 
the released state, so the procedure in 
Figure 4 handles the released state. 
When the pushbutton is in a pressed 
state, PM paints the pushbutton in a 
different style - it creates an illusion 
of a three-dimensional button being 
pressed, then adds the title to the 
pushbutton. To simulate this, we 
must follow the same process. It is 
not sufficient to trap WM_PAINT; we 
also have to trap BM_SETHI LITE - a 
message that is generated when the 
pushbutton is suppressed - and then 
let the process flow in the same 
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case WM_CREATE: 





hWndButton - WinCreateWindow 

(hWnd, 

/* 

Client handle 

*/ 


WC_BUTT0N, 

/* 

Register Class 

*/ 


M ” 

/* 

Window - Title 

*/ 


BS_PUSHBUTTON,/* 

Button style 

*/ 


0, 0, 

/* 

Coordinates 

*/ 


0. 0, 

/* 

Si ze 

*/ 


hWnd, 

/* 

Parent window 

*/ 


HWND_T0P, 

/* 

Position 

*/ 

break; 

PBD_0K, 

NULL, NULL); 

/* 

Window ID 

*/ 


Figure 1. The WM CREATE Message in a Client Window Procedure 


case WM_SIZE: 


scxClient = SH0RT1FR0MMP (mp2); 


scyClient = SH0RT2FR0MMP (mp2); 


WinSetWindowPos(hWndButton, 

/* Pushbutton handle */ 

HWND_T0P, 

/* Relative position */ 

xPos, yPos, 

/* Actual position */ 

cXfact * scxClient, 


cYfact * scyClient, 

/* calculated size of pushbutton */ 

SWP_SH0W | SWP_SIZE 

| SWP_M0VE); 

break; 



Figure 2. The WM SIZE Message in a Client Window Procedure 


case WM^CREATE: 


hWndButton = WinCreateWindow (...); 

ButtonCntrl Proc = WinSubcl assWindow (hWndButton, ButtonWndProc); 


break; 


Figure 3. Modified WM_CREATE in a Client Window Procedure 
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MRESULT EXPENTRY ButtonWndProc(HWND hWnd, 

USHORT msg. 
MPARAM mpl, 
MPARAM mp2) 

{ 

RECTL rClient; 


switch(msg) 

{ 

case WM_PAINT: 

/* Get the size of the pushbutton, resize the font */ 
/* according to the size, and paint the text. */ 

WinQueryWindowRect( hWnd, &rClient); 

PaintPushButton(hWnd, rClient); 
break; 


default: 

return((*ButtonCntrlProc)(hWnd, msg, mpl, mp2)); 

} 

return(FALSE); 

} 


Figure 4. Preliminary Subclass Window Procedure ButtonWndProc 


MRESULT EXPENTRY ButtonWndProc(HWND hWnd, 

USHORT msg, 

MPARAM mpl. 

MPARAM mp2) 

{ 

RECTL rClient; 

BOOL bRetval; 

switch(msg) 

{ 

case BM_SETHILITE: 
case WM_PAINT: 

/* Let the default window procedure paint first. */ 
bRetval - (BOOL) SH0RT1FR0MMP((*ButtonCntrlProc) 

(hWnd, msg. mpl, mp2)); 

/* Get the size of the pushbutton, resize the font */ 
/* according to the size, and paint the text. */ 

WinQueryWindowRect(hWnd, &rClient); 

PaintPushButton(hWnd. rClient); 
return(MPFR0MSH0RT(bRetval)); 

default; 

returnC(*ButtonCntrlProc)(hWnd, msg, mpl, mp2)); 

} 

returnC FALSE); 

} 


fashion. We let PM paint the pushbut¬ 
ton first, creating the illusion of a 3- 
D button being pressed, and then we 
paint the title on the pushbutton. This 
involves a small change in the sub¬ 
class procedure, which is shown in 
Figure 5 in its final form. 
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software engineer at Computer 
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user interface to a cooperative 
processing application for a steel 
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hased network application for a 
cable company. Mr. Tatikola has 
a Bachelor of Engineering degree 
in electronics and communication 
engineering from Osmania Uni¬ 
versity , India and an MS in com¬ 
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Computer Aid, Inc. 
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Figure 5. Final Subclass Window Procedure ButtonWndProc 
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Configuring Parallel Ports 
for OS/2 

Frank J. Schroeder 
IBM Corporation 
Boca Raton, Florida 

This article explains parallel port configuration for OS/2 , including how 
parallel-port address ranges and hardware interrupt levels have evolved 
and how some manufacturers have extended the standard. It reviews how 
DOS and OS/2 drive parallel ports , and how bus architectures affect the 
use of parallel ports. Finally , the article gives remedies for configuration 
problems. 


W hen upgrading from DOS to 
OS/2, some users encounter 
configuration problems that 
affect printers attached to parallel 
ports. At first glance, the problem 
may appear to be with OS/2, because 
the hardware worked correctly under 
DOS. In reality, the parallel port may 


never have been configured appropri¬ 
ately under DOS, but since DOS never 
used the incorrectly configured op¬ 
tions, the error was not apparent. OS/2 
takes advantage of certain parallel 
port features that DOS does not, so 
often the solution is simply to config¬ 
ure the parallel ports properly for OS/2. 


Evolution of Parallel Ports 

Parallel-port address ranges and hard¬ 
ware interrupt levels have evolved 
over time. The IBM Personal Com¬ 
puter, introduced in 1981, came with 
a Monochrome Display/Printer 
Adapter. This combination adapter 
was designed for driving a mono¬ 
chrome monitor and for attaching 
parallel port devices, such as the IBM 
5152 Graphics Printer. On this adapt¬ 
er, the parallel port was designed to 
use the 3BC port address range and 
the primary parallel port hardware in¬ 
terrupt level, IRQ7. Both the address 
range and hardware interrupt level 
were fixed; they could not be altered 
because there were no DIP switches 
or jumpers on the adapter card. 

As the need arose to attach more 
serial and parallel devices to system 
units, IBM introduced the Serial/ 
Parallel Adapter. This adapter allowed 
users to configure the address ranges 
and hardware interrupt levels of the 
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Figure 2. IBM Personal Computer AT Bus Parallel Port Address and Interrupt Level 
Configurations 


Logical Name 

Adapter Name 

Address Range 

Interrupt Level 

LPT1 

PARALLEL 1 

3BC-3BE 

IRQ7 

LPT2 

PARALLEL2 

378-37A 

IRQ7 

LPT3 

PARALLEL3 

278-27A 

IRQ7 


Figure 3. IBM PS/2 Micro Channel Bus Parallel Port Address and Interrupt Level 
Configurations 


serial and parallel ports; with this 
capability, two Serial/Parallel adapters 
could be installed in one system. The 
J1 (serial) and J2 (parallel) jumpers 
on the adapter could be set to two dif¬ 
ferent settings, as shown in Figure 1. 
The first parallel port setting was for 
the 378 port address range and the 
primary parallel-port hardware inter¬ 
rupt level (IRQ7). The second setting 
was for the 278 port address range 
and the alternate parallel-port hard¬ 
ware interrupt level (1RQ5). 

The combination of one Monochrome 
Display/Printer Adapter and two 
Serial/Parallel Adapters enabled the 
use of three parallel ports in one sys¬ 
tem and created the de facto standard 
for AT-bus systems running DOS 
today. 

Figure 2 shows the parallel port ad¬ 
dress ranges and hardware interrupt 
levels for the three parallel ports on 
the IBM Personal Computer AT bus. 

In 1987, IBM introduced the Per¬ 
sonal System/2® and Micro Channel 
architecture. In the PS/2, IBM carried 
forward the PC AT’s port address 
ranges and hardware interrupt levels 
to maintain compatibility with exist¬ 
ing software. Prior systems had re¬ 
quired the purchase of adapter cards 
to gain features such as a serial or 
parallel port, an auxiliary port, or a 
video port. All these ports, standard 
equipment in PS/2 Micro Channel 
systems, improve performance and 
value. The system board parallel port 
can have any setting described in Fig¬ 
ure 3. (Currently, IBM does not pro¬ 
duce a parallel port adapter for Micro 
Channel systems. However, several 
adapter manufacturers have filled 
this niche.) Micro Channel adapter 
cards can be configured to any of the 
settings in Figure 3 as long as the 
address range does not conflict with 
any other installed parallel port. 

More recently, IBM has introduced 
PS/2 systems that contain the AT 


Figure 1. IBM Serial/Parallel Adapter 


bus. Unlike the original PC AT, these 
systems include the same built-in ports 
found in Micro Channel systems, 
again offering improved performance 
and value. To configure system 
board and adapter parallel ports in a 
PS/2 system that has an AT bus, see 
Figure 2. 

Extensions by IBM-Compatible 
Manufacturers 

IBM personal computers are open 
systems. This means IBM publishes 


its hardware and software interfaces 
so that other manufacturers can pro¬ 
vide special-purpose adapter cards 
and software to run on IBM systems. 
Some of these manufacturers also 
produce IBM-compatible personal 
computers that can use these adapter 
cards and software. Some manufac¬ 
turers extend the definition of the 
parallel port for assigning either the 
IRQ5 or IRQ7 hardware interrupt 
level to any of the three parallel port 
address ranges, as shown in Figure 4. 


PERSONAL SYSTEMS / OCTOBER 1992 




























































68 



Figure 4. ISA and EISA Bus Parallel Port Address and Interrupt Level Configurations 


Logical Name 

Adapter Name 

Address Range 

Interrupt Level 

LPT1 

PARALLEL 1 

3BC-3BE 

IRQ7 

LPT2 

PARALLEL2 

278-27A 

IRQ5 

LPT1 

PARALLEL2 

378-37A 

IRQ7 

LPT2 

PARALLEL3 

278-27A 

IRQ5 


Figure 5. Two Parallel Port Combinations for an ISA System Running OS/2 


This is done primarily in computers 
based on Industry Standard Architec¬ 
ture (ISA), which is compatible with 
the PC AT bus and with those based 
on Extended Industry Standard 
Architecture (EISA). 

Assignment of Logical 
Device Names 

No matter which combination of 
address range and hardware interrupt 
level is configured, DOS and OS/2 
assign the first installed address 
range in these tables to logical device 
name LPT1, the next to LPT2, and so 
on. For example, if the 3BC address 
range is configured, the operating sys¬ 
tem assigns it to logical device LPT1. 
If the 3BC address range is not in¬ 
stalled, but the 378 address range is 
installed, the operating system assigns 
378 to logical device LPT1. If the 
278 address range is also installed, 
the operating system assigns it to 
logical device LPT2 because it is 
next in the table. Only two parallel 
ports are configured, so no parallel 
port corresponds to LPT3. Since data 
directed to LPT3 cannot be physical¬ 
ly transmitted, the operating system 
discards it. 


DOS Parallel Port 
Configuration 

DOS uses the Basic Input/Output Sys¬ 
tem (BIOS) interrupt 17h function to 
transmit data through the parallel 
port to a printer. The BIOS uses the 
port address ranges to program the 
parallel port hardware. A technique 
called polling transmits data to the 
parallel-attached device. The polling 
technique does not use the hardware 
interrupt capability of the parallel 
port, so DOS ignores the interrupt 
levels. Although some manufacturers 
extend the hardware interrupt capa¬ 
bility of the parallel port, this does 
not adversely affect DOS users. 

OS/2 Parallel Porf 
Configuration 

Unlike DOS, OS/2 takes advantage 
of the hardware interrupt capability 
of the parallel port. In OS/2, both the 
port address and the hardware inter¬ 
rupt level are important. OS/2 runs 
on AT, EISA, and Micro Channel 
bus systems. AT-bus (ISA) systems 
use edge-triggered interrupts, while 
EISA and Micro Channel systems 
use level-sensitive interrupts. On ISA 
systems, hardware interrupt levels 
cannot be shared by devices, but on 
EISA and Micro Channel systems the 


hardware interrupt levels can be 
shared. The caveat is that ISA adap¬ 
ters cannot share interrupt levels 
when installed in EISA bus systems. 

OS/2 and ISA Systems 

To install one parallel port on an ISA 
system running OS/2, configure the 
parallel port with any address range 
and interrupt level pair, shown in 
Figure 2. 

To install two parallel ports on an 
ISA system running OS/2, refer to 
the valid combinations for two paral¬ 
lel ports, as shown in Figure 5. (Be¬ 
cause ISA systems do not support 
hardware interrupt sharing, the two 
port configurations shown in Figure 
2 that use interrupt level IRQ7 
should not be used together.) 

To install three parallel ports on an 
ISA system running OS/2, configure 
the adapters exactly as specified in 
Figure 2. As you may have noticed, 
Figure 2 shows two devices using 
hardware interrupt IRQ7. This seems 
contradictory, because ISA systems 
cannot share hardware interrupt 
levels. How can both work? 

The OS/2 parallel-port device driver 
is responsible for the algorithm used 
to transmit data through the parallel 
port. When a print request is issued 
to LPT1 and LPT2 is idle, there is no 
conflict with the hardware interrupt 
level. The request to print on LPT1 
can proceed using IRQ7. Conversely, 
if a print request is issued to LPT2 
and LPT1 is idle, there is still no 
conflict with the hardware interrupt 
level. The request to print on LPT2 
can proceed using IRQ7. But what 
happens when LPT 1 is printing and, 
before it completes, a request to print 
is issued to LPT2 (or vice versa)? 

To run the second device (LPT2) that 
is requesting the hardware interrupt 
level IRQ7 while the first one (LPT1) 
is still running, the OS/2 parallel-port 
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device driver initially uses the OS/2 
timer services. The OS/2 timer ser¬ 
vices use the real-time clock and gen¬ 
erates hardware interrupts at a rate of 
18.2 times per second. This interrupt 
frequency is significantly slower than 
the interrupt frequency achievable 
using a device-generated hardware 
interrupt level. If the LPT2 request is 
left to run only on the timer services, 
the request would take an unacceptab¬ 
ly long time to complete. To work 
around this resource conflict, when 
the interrupt-based request (LPT1) 
completes transmission of its buffer, 
the device driver switches the timer- 
based request (LPT2) to the hardware 
interrupt level. When the first request 
(LPT1) returns with more data to 
transmit, the device driver assigns it 
to the system timer. It stays there 
until the second request (LPT2) - 
which is now at the hardware inter¬ 
rupt level - completes. This process 
of switching print requests between 
the hardware interrupt level and the 
system timer continues until the 
resource conflict ceases. 

If the request assigned to the hard¬ 
ware interrupt level stops transmit¬ 
ting because of device errors (such as 
out of paper, offline, and power off), 
then that request is similarly switched 
to the system timer. This frees the 
(faster) hardware interrupt level for 
use by a request from another device. 
That request will then operate at max¬ 
imum throughput. 

OS/2 and EISA Systems 

One, two, or three EISA parallel 
ports can be configured to run under 
OS/2. How these parallel ports are 
configured depends on which other 
adapters are running on the same 
hardware interrupt level, their interrupt 
sharing capability, and the interrupt 
sharing capability of the parallel port 
adapter. If the parallel port or other 
adapter cards on this level cannot 
share interrupts, then the parallel port 
must be configured as specified in 


Figure 2. Hardware interrupt level 
contention must be resolved. If the 
parallel port and other adapters on 
the same hardware interrupt level can 
share interrupts, then the parallel port 
can be configured to use either inter¬ 
rupt level, as specified in Figure 4. 

Be sure to make the correct decisions 
when using EISA configuration soft¬ 
ware. Since that software cannot 
detect the presence of ISA hardware, 
it does not prevent a configuration 
mistake. 



Micro Channel adapter 
configuration is easier 
than EISA adapter 
configuration. 


EISA configuration software lets you 
set any of the possible configuration 
alternatives. However, it will not pro¬ 
vide an alert when you have made an 
error. If the hardware does not sup¬ 
port the alternative selected, OS/2 
may not be able to operate the adapt¬ 
er card. For example, if a parallel 
port adapter does not support hard¬ 
ware interrupt sharing, only one 
adapter can be assigned to that par¬ 
ticular hardware interrupt level. If a 
parallel port adapter uses address 
range 278 and supports interrupts on 
IRQ5 only, but the user sets the inter¬ 
rupt level to IRQ7 through the set 
configuration software, then OS/2 
will incorrectly drive the adapter 
from IRQ7. It is important to know 
whether the adapter supports hard¬ 
ware interrupt sharing, on what level, 
and what address range it uses. 

OS/2 and Micro Channel Systems 

To install one, two, or three parallel 
ports on a Micro Channel system and 
run them with the OS/2 parallel-port 
device driver, the adapters must be 


configured as specified in Figure 3. 
Any combination of the address 
ranges (except duplicates) can be 
specified if all the hardware interrupt 
levels are specified as IRQ7. 

The Micro Channel bus architecture 
supports hardware interrupt sharing. 
The hardware interface used by the 
device driver to transmit the data on 
Micro Channel parallel ports can 
specify whether the device is gener¬ 
ating an interrupt. This hardware 
feature enables interrupt sharing to 
work. The OS/2 parallel port device 
driver takes advantage of this feature. 
When a print request is issued to any 
of these devices, the OS/2 parallel 
port device driver uses IRQ7 to 
transmit the data. 

There is an exception to the IRQ7- 
only restriction. If a Micro Channel 
adapter manufacturer provides both 
a parallel port adapter that can inter¬ 
rupt on 1RQ5 and a loadable OS/2 
parallel-port device driver, then the 
adapter can be configured to run on 
IRQ5 under OS/2. Follow the manu¬ 
facturer’s recommendations for load¬ 
ing the loadable OS/2 parallel-port 
device driver. Most Micro Channel 
adapters that can interrupt on IRQ5 
can also interrupt on IRQ7; conse¬ 
quently, they can be run by the OS/2 
parallel-port device driver. 

Micro Channel adapter configuration 
is easier than EISA adapter configura¬ 
tion, because there is no need for con¬ 
cern about which adapters support 
interrupt sharing - they all do with 
Micro Channel. 

Configuring the Parallel Port 

There are several suggested actions 
to correct a parallel port problem. 

First and easiest is to check the con¬ 
figuration of the parallel ports in¬ 
stalled in your system. If you are 
running on an ISA system, turn off 
the power, remove the cover of your 
system unit, and check the DIP 
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switches and jumpers. The documen¬ 
tation that accompanies the parallel- 
port adapter card or the system unit 
should show the appropriate settings 
for DIP switches and jumpers. 

EISA and Micro Channel systems 
have a software configuration option. 
In Micro Channel systems, software 
can customize the configuration, so 
there is no need to power off the sys¬ 
tem unit or remove the system unit 
cover to check or modify the config¬ 
uration. Just insert the reference (con¬ 
figuration) diskette that comes with 
the system unit into the A: drive and 
reboot. You will see a menu contain¬ 
ing an option to set the configuration. 
Follow the directions given with the 
Set Configuration program to con¬ 
figure the parallel ports appropriate¬ 
ly. EISA systems can be similarly 
configured by software unless an ISA 
adapter is installed; ISA adapters 
must be configured by physically 
modifying DIP switches or jumpers. 

If a parallel port adapter is installed 
after the system unit, use the EISA 
configuration file (. C FG) or the 
Micro Channel Adapter Description 
File (. ADF) distributed with the new 
adapter to configure it. There is an 
option to copy the particular file 
from the adapter’s diskette to the 
system reference diskette. During 
system configuration, when the Set 
Configuration program cannot find 
the file on the reference diskette, it 
prompts you to insert the diskette that 
contains the file. If you have two 
parallel ports installed, make sure the 
adapters do not use the same address 
range. The PS/2 Set Configuration 
program provides alerts about con¬ 
flicts like this, whereas EISA con¬ 
figuration software cannot. 

Direct Memory Access 

The system-board parallel port on 
PS/2 Models 56, 57, 80-A21, 80-A31, 


90, and 95 supports a feature called 
Direct Memory Access (DMA). 

DMA provides increased throughput 
and system performance. Running on 
Micro Channel systems, OS/2 recog¬ 
nizes and automatically takes advan¬ 
tage of DMA parallel support if the 
DMA feature is configured properly. 
(DOS does not exploit the DMA 
parallel feature.) The Set Configura¬ 
tion option, found on the main menu 
of the PS/2 Reference Diskette, can 
verify that the DMA option is sup¬ 
ported and enabled. The Set Config¬ 
uration option displays the current 
system setup, and in particular, the 
parallel port name and parallel-port 
arbitration level (found under Built- 
In Features). By default, the parallel 
port is set to PARALLEL 1 (3BC and 
IRQ7) and its arbitration level is set 
to SHARED7, which means DMA is 
enabled. Cycle through the available 
arbitration level options and select the 
DISABLE option to disable the paral¬ 
lel port DMA. Using the DMA paral¬ 
lel option is highly recommended on 
PS/2 systems that support it. 

OEM Incompatibilities 

Two other scenarios, categorized as 
Original Equipment Manufacturer 
(OEM) incompatibilities, are worth 
noting. The first problem occurs 
when the OEM parallel port does not 
generate hardware interrupts, gener¬ 
ates them incessantly, or generates 
them spuriously. This results when 
the parallel port hardware does not 
contain interrupt logic or the logic is 
faulty. The second problem occurs 
when the parallel port generates 
hardware interrupts on a nonstandard 
hardware interrupt level and the 
manufacturer does not provide a way 
to modify the level (DIP switches, 
jumpers, or a set configuration pro¬ 
gram). For example, when the manu¬ 
facturer sets the port address to 3BC 
or 378 and the hardware interrupt 
level to IRQ5 on AT or Micro Chan¬ 


nel bus systems, the configuration 
cannot be changed to resolve the in¬ 
compatibility. Incompatibilities can 
occur on either the system board or 
adapter-card parallel port. Clearly, if 
the problem is on an adapter card, it 
is a less expensive and a less disrup¬ 
tive problem to fix. 

Alternatives exist when a parallel 
port has interrupt problems. The sys¬ 
tem board or adapter-card parallel 
port can continue to be driven in a 
non-interrupt fashion by DOS. 
Another alternative is to contact the 
manufacturer to explain the problem, 
determine whether the manufacturer 
is aware of the problem, and ask if a 
revision is available. 

Conclusion 

Parallel port configuration under 
OS/2 may be an issue of concern. 
Fortunately, configuration is general¬ 
ly a simple process. Usually it takes 
just a few minutes to change DIP 
switches or jumpers, or to run a pro¬ 
gram to set the configuration. In 
other cases the hardware may not be 
truly IBM-compatible, and will not 
run under OS/2 without specialized 
(nonstandard) device drivers to sup¬ 
port the parallel ports. 


Frank J. Schroeder is a staff pro¬ 
grammer in the OS/2 Device 
Drivers and Multiple Virtual DOS 
Machines (MVDM) department. 
Frank has worked on OS/2 since 
Version 1.0 and is currently work¬ 
ing on performance and function¬ 
al enhancements to the OS/2 
Printer Subsystem. Fie has a 
Bachelor of Technology degree in 
computer science from Rochester 
Institute of Technology and an 
MBA from the University of 
Miami. 
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Performance Characteristics of 
ES 1.0 Database Manager 

Benetta N. Perry, Harry Shelin Chen, Bob Russell, and Timothy J. Li 
IBM Corporation 
Austin, Texas 

This article describes some performance characteristics of the IBM 
Extended Services (ES) 1.0 Database Manager running with OS/2 2.0. It 
gives insights into system performance through various test cases , bench¬ 
marks , and (i what-if f scenarios. The information in this article should 
help users configure and use ES 1.0 more efficiently. 


T his article describes some per¬ 
formance characteristics of Data¬ 
base Manager in IBM Extended 
Services for OS/2 1.0 (ES 1.0) run¬ 
ning with OS/2 2.0: 

• Single workstation scenario: Per¬ 
formance measurements are made 
on key database functions for local 
and remote operations. Sensitivity 
studies show the effects of tuning 
some parameters. 

• Transaction processing applica¬ 
tions: Multi-user transaction proc¬ 
essing measurements are made 
based on the book order bench¬ 
mark defined by the National Soft¬ 
ware Testing Laboratories (NSTL). 
The effects of parameter tuning 
and communication protocol on 
product performance are demon¬ 
strated. Comparisons with the 
predecessor, IBM OS/2 Extended 
Edition 1.3, also are made. 

• Forward recovery: This is a new 
set of functions in ES 1.0 Database 
Manager. The key questions about 
the performance of forward recov¬ 
ery are “How much does system 
performance degrade because of 
archival logging?” and “How long 
does it take to perform forward 
recovery when needed?” These 
questions are addressed using one 
of NSTL’s benchmarks. 


System Configuration 

Measurements presented in this 
article use a 33 MHz IBM PS/2 
Model 95 for the database server. 
The amount of memory depends on 
the test cases: for the single worksta¬ 
tion scenario, it is 16 MB; for trans¬ 
action processing applications it is 
32 MB. These memory sizes are not 
required for the test cases; they were 
chosen to prevent memory overcom¬ 
mitment during the benchmarks. 

The database server and its clients 
are connected by a 4 MB token ring. 


All benchmarks are performed using 
the ES 1.0 Database Manager prod¬ 
uct running with the OS/2 2.0 operat¬ 
ing system. 

Performance in Single 
Workstation Scenarios 

The single client scenario uses a 16 
MHz PS/2 Model 80-071 with SMB 
of memory and one 115 MB disk. Net¬ 
BIOS is the communication protocol. 

Most of the database and Database 
Manager configuration parameters 
are set with their default values. The 
exceptions are that the maximum stor¬ 
age of the lock list is changed from 
the default of 8 to 25 4-KB pages, 
and the database heap size (DBHEAP) 
is changed from the default of 3 to 10 
segments. During the performance 
measurements, some configuration 
parameters are varied to demonstrate 
their effects on performance. 

All the database tables use the same 
table definitions and contain the same 
number of fields, as shown in Figure 
1. The differences in the tables are 
in the number of rows in a table, the 
indices defined, and the range of data 
values for the fields. The table sizes 


Column I Width I Type I Ordering 


Field 1 


Integer 

Ordered 

Field2 


Integer 

Unordered 

Field3 


Integer 

Unordered Rep 

Field4 

21 

Character 

Ordered 

Field5 

21 

Character 

Unordered 

Field6 

21 

Character 

Unordered Rep 

Field7 

5,0 

Decimal 

N/A 

Field8 


Scientific 

N/A 

Field9 


Date 

Random 

Field 10 


Integer 

Ordered 

Field 11 


Integer 

Unordered 

Field 12 


Integer 

Unordered Rep 

Figure 1. 

Database Table Definitions 
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Function I Local I Remote 


Update 1,000 rows 

10.5 seconds 

10.8 seconds 

Insert 1,000 rows 

12.1 seconds 

13.2 seconds 

Delete 1,000 rows 



- without index 

4.8 seconds 

5.1 seconds 

- with index 

32.8 seconds 

32.8 seconds 


Figure 2. Basic Functions that Change the Database 



1 Row & Sort Complex 


Figure 3. Effects of Indexing on Selects 



Figure 4. Effects of Table Size on Remote Select All 


used in the measurement include 
10,000, 20,000, 30,000, 40,000, 
50,000, and 100,000 rows. Indices 
are defined on the first three fields of 
the tables. 


Implementation of Test Cases 

The test cases are implemented in the 
C language with embedded Struc¬ 
tured Query Language (SQL) state¬ 
ments. Within each test run, a Start 
Using Database command is issued 
before each query begins, and a Stop 


Using Database command is issued 
after each query ends. This causes 
the buffer pool to be emptied, ensur¬ 
ing the consistency of the results. 

The time recorded is the elapsed time 
of the query, excluding the time for 
the Start and Stop Using Database 
commands. 

Base Measurement Results 

Figure 2 shows performance results 
for the basic functions of changing 
the database with Update, Insert, and 
Delete. The Update is performed on 
an indexed 10,000-row table. The 
Insert is from an indexed 10,000-row 
table into an empty table. In all cases, 
the differences in response time are 
small between local and remote oper¬ 
ations because these operations pass 
only a small amount of data between 
the client and the server. 

Deleting 1,000 rows with an index 
takes substantially more time than 
without an index. When deleting with 
an index, changing indices by restruc¬ 
turing the B-tree takes a large amount 
of time, although the index helps to 
quickly find the rows to be deleted. 

Figure 3 shows performance results 
of various forms of selects from a 
100,000-row table. The Select One 
Row case has a simple predicate. The 
Select Complex case has a complex 
predicate that returns 20 rows. The 
Select and Sort case evaluates a 
complex predicate and then sorts the 
selected rows; it also returns 20 rows. 
Note the drastic difference in perfor¬ 
mance between the indexed and non- 
indexed cases. These results clearly 
demonstrate the importance of proper 
index design. 

Generally, the elapsed time increases 
as the amount of data returned in¬ 
creases. Figure 4 shows the effect of 
table size for a Remote Select of all 
rows in the table. The time increases 
linearly as the size of the table in¬ 
creases. For this test, record blocking 
is used, with a block size of 4 KB. 
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Figure 5 shows the elapsed time for a 
select with an Order By query that 
returns the entire table. Rows are 
stored in the same order as that speci¬ 
fied in the Order By clause, so the 
sort time is minimized. Still, selects 
on indexed tables are consistently 
faster than on tables without indices. 
If an index (on the column given in 
the Order By clause) exists, then 
rows can be retrieved in the desired 
order with no sorting at all. 

Figure 6 shows the elapsed time of a 
two-table join. As the result of join¬ 
ing the table that has 20,000 rows 
with the table that has 30,000 rows, 
about 30,000 rows are selected. 
Response time is plotted against 
buffer pool size for tables with and 
without indices. 

With the default buffer pool size 
(1,000 KB), the join with index takes 
longer than without index. This is 
caused by the extra Input/Output 
(I/O) for reloading the index into the 
buffer pool when the buffer pool size 
is inadequate. However, when the 
buffer pool size increases, the elapsed 
time for the indexed case starts to 
improve, while the performance for 
the non-indexed case remains almost 
constant. When the buffer pool is 
large enough, the indexed case out¬ 
performs the non-indexed case, as 
expected. 

Utilities 

Several utilities are described below. 

Create Index: Figure 7 shows the 
performance of Create Index for two 
cases - when the records are sorted 
on the index key, and when the rec¬ 
ords are in random order. For sorted 
input, the elapsed time is less. It is 
also proportional to the size of the 
table. Sorted inputs minimize the I/O 
needed to build the B-tree for the 
index. When the field is unsorted, 
much I/O may be needed to get the 
nodes to insert when building the 
B-tree. The performance of Create 



Figure 5. Select All Rows with Order By Query 



Figure 6. Effects of Indexing and Buffer Pool on a Two-Table Join 



Figure 7. Create Index for Sorted and Unsorted Records 
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Figure 8. Import Without Index and With Index 



Figure 9. Reorg and Runstats Utilities 


Index depends on many factors, 
including the number of rows in the 
table, the complexity of the index, 
the length of the indexed fields, the 
size of the buffer pool, and the ran¬ 
domness of the indexed fields. 

Import: Figure 8 shows the elapsed 
time for importing a table from a 
delimited ASCII file into the database. 
If no index is defined, the elapsed 
time increases linearly as the number 
of imported rows increases. With an 
index, the elapsed time is longer than 
the non-indexed case, and it increases 
faster than linearly. Additional proc¬ 
essing is required to build the B-tree 


for the index. In the non-indexed 
case, the new table can be written to 
disk sequentially, whereas each new 
record added to an indexed table re¬ 
quires additional disk I/O to update 
the index. The increase in response 
time with table size is greater than 
linear because the depth of the B-tree 
grows with the table size, increasing 
the average number of disk operations 
needed to add each record. The extent 
of the increase depends on the num¬ 
ber and complexity of the indices 
defined, the randomness of the data 
in the indexed fields, and the size of 
the buffer pool. 


Reorg and Runstats: Figure 9 shows 
the performance of the Reorg and 
Runstats utilities. The time for Run¬ 
stats increases linearly as the number 
of rows in the table increases, while 
Reorg increases more drastically. 

This is expected; because Runstats 
goes through the table to gather statis¬ 
tics uniformly, the elapsed time should 
be proportional to the size of the 
table and its indices. For Reorg, how¬ 
ever, the system rebuilds the table for 
data and the B-tree for indices. The 
rebuilding of the B-tree generally 
causes a more drastic increase as the 
table size increases. 

Parameter Tuning 

In ES 1.0 Database Manager, many 
database configuration parameters 
can be easily modified with the con¬ 
figuration tool. Thus, users can select 
parameter values that are well suited 
to their applications. The following 
examples show how tuning some 
configuration parameters improves 
performance. 

Buffer Pool: Figure 10 shows the 
transient behavior for repeated single 
random selects. The operation starts 
with an empty buffer pool. Average 
response time is calculated for every 
100 random selects. The average 
response time for each 100 selects 
gradually decreases, then stabilizes. 
Initially the buffer pool is empty, so 
the chance of finding the randomly 
selected row is low. Then, as more 
data and index pages are read into the 
buffer pool, the hit ratio increases 
and average response time drops. 

The best steady state results are at¬ 
tained when all the data and index 
pages within the selected range are 
in the buffer pool - that is, with an 
almost 100% hit ratio. 

Effects of Buffer Pool on Random 
Selects: Figure 11 shows the effects 
of a buffer pool on random selects 
with various ranges. A single select 
is made from a 100,000-row table 
with index. Each curve in this figure 
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represents random selects from a dif¬ 
ferent range of field values. The field 
for the select criterion follows the 
natural ordering of the data in the 
table. Thus, the range for the random 
select determines the portion of the 
table that is accessed. 

For selects in the range 1 to 10,000, a 
2,000 KB buffer pool is more than 
sufficient to hold all the data and in¬ 
dices. The hit ratio is already 100%. 
Further increasing the buffer pool 
size will not improve the perfor¬ 
mance. For selects in the range 1 to 
100,000, the maximum buffer pool 
size of 6,000 KB still cannot hold all 
the data and index pages. Thus, the 
hit ratio is far less than 100%. 

The buffer pool size should be esti¬ 
mated by running benchmarks that 
reflect the real database applications. 

Record Blocking: Record blocking 
often improves performance of remote 
selects from a client by reducing the 
number of messages sent between the 
client and the database server. Figure 
12 shows the elapsed time of select¬ 
ing all rows of a table as a function 
of the block size for the data transfer. 
A block size of zero means no record 
blocking is used. The most dramatic 
improvement is from no record block¬ 
ing to using record blocking with a 
block size of 4 KB. Further increases 
in block size have only marginal 
return in performance. The elapsed 
time is proportional to the amount of 
data transferred. 

Performance for Transaction 
Processing Applications 

The hardware configuration is equiv¬ 
alent to the setup that NSTL used for 
their recent measurement report 
(“SQL Servers for LANs,” Software 
Digest Rating Report. 1991, Volume 
8, Number 15.). The database server 
is a 33 MHz IBM PS/2 Model 95 with 
32 MB of memory. 



Figure 10. Transient Behavior of Random Select 



Figure 11. Select on Random Key Value with Various Ranges 



Figure 12. Effects of Record Blocking 
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Figure 13. Effect of Buffer Pool Size on ISBN Order 


ISBN Order scenario is a test that 
uses an International Standard Book 
Number (ISBN) to order the book 
desired. 

Shipment is a program that finds the 
lowest order number for an unshipped 
order. It selects the ORDER record 
for that number and all corresponding 
entries, and updates the ORDER rec¬ 
ord. The program also updates BOOK 
records with ISBN numbers that cor¬ 
respond to the selected entry records. 

Payment scenario selects the ORDER 
record and its corresponding entries. 
The ORDER record is updated. 



Figure 14. Effect of Buffer Pool Size on Author Order 


The key configuration parameters for 
Database Manager (DBM) are set as 
follows. 

Number of shared segments = 802 
Requester I/O block size = 16 KB 
Server I/O block size = 16 KB 
Remote connections =120 
Communication heap = 3 

The key configuration parameters for 
the database are set as follows: 

Buffer pool size = 1,500 4-KB pages 
Lock list size = 25 
Log file size = 1,000 
Number of primary logs = 4 
Number of secondary logs = 0 


Benchmark Definition 

To test the SQL database server per¬ 
formance, NSTL has developed the 
database and its applications for book 
order entry. This database includes 
the key tables BOOK, AUTHOR, 
LINK, ORDER, and ENTRY. The 
application includes five scenarios: 
Title Order, Author Order, ISBN 
Order, Shipment, and Payment. 

Title Order scenario is a test that 
simulates customers who know only 
part of the title of a book that they 
want to order. 

Author Order scenario is a test that 
simulates customers who know only 
part of the author’s name. 


Where applicable, an Application 
Remote Interface (ARI) is imple¬ 
mented for better performance. For 
each scenario, multi-user cases are 
tested. No “think time” is inserted 
between the transactions. For more 
details about this benchmark, see the 
NSTL measurement report cited above. 

Base Measurements 

Figures 13, 14, and 15 show the 
effects of buffer pool size on the 
response time for the ISBN Order, 
Author Order, and Payment scenar¬ 
ios, respectively. For the first two 
scenarios with many users, the perfor¬ 
mance is very sensitive to the buffer 
pool size. However, in the Payment 
scenario, performance is much less 
sensitive to the buffer pool size. This 
demonstrates again that the effect of 
a buffer pool depends on the nature 
of the scenario being run. 

Figure 16 shows the effects of com¬ 
munication protocols on the response 
time for the Author Order scenario. It 
indicates that for this scenario. Ad¬ 
vanced Peer-to-Peer Network (APPN) 
has a slight edge over NetBIOS. Gen¬ 
erally, when a small amount of data 
is transferred, APPN often performs 
better than NetBIOS. The default 
protocol is NetBIOS, which is easy 
to configure and to get the system 
started. When the difference in per- 
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formance becomes significant, it may 
be desirable to spend time and effort 
to configure for the APPN protocol. 

Figures 17 through 21 compare the 
performance of ES 1.0 with its pre¬ 
decessor, OS/2 Extended Edition 
(EE) 1.3. Clearly, the current system 
consistently outperforms its predeces¬ 
sor. The improvement is very signifi¬ 
cant with a large number of users. 

The main reason for this improvement 
is the difference in how the base oper¬ 
ating system addresses memory. The 
predecessor system can address only 
16 MB of memory, even though 
more physical memory is installed in 
the server hardware. With the buffer 
pool set at 6 MB and a large number 
of users, OS/2 EE 1.3 overcommits 
memory, extensive swapping occurs, 
and performance degrades drastically. 
Because OS/2 2.0 can address much 
larger memory spaces, all the mem¬ 
ory available in the hardware can be 
used. Thus, the response time curve 
remains linear, even for many users. 

Measurements with Archive Logging 

Forward recovery with archival log¬ 
ging is a new function supported by 
the ES 1.0 Database Manager. The 
performance degradation from ar¬ 
chival logging is a valid concern. To 
investigate this effect, the NSTL Pay¬ 
ment scenario with sixteen users was 
run with no “think” time. For this set 
of tests, there were four primary log 
files of 200 4-KB pages each. 

To establish a base line for compari¬ 
son, this scenario was run using a 
circular log. Then the same scenario 
was repeated with log retain and ar¬ 
chival logging with different media. 
Log retain provides logging on the 
hard disk instead of circular logging; 
the hard disk log can be manually 
archived later (offline) to a different 
medium. For archival logging, the 
media used was a 340 MB disk in the 
server, an IBM PS/2 Rewritable Opti¬ 
cal Disk (128 MB), and an IBM PS/2 
2.3 GB Small Computer Systems 



Figure 15. Effect of Buffer Pool Size on Payment 



Figure 16. Effect of Communication Protocol on Author Order 



Figure 17. Comparison of ES 1.0 and OS/2 EE 1.3 for ISBN Order 
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Figure 18. Comparison of ES 1.0 and OS/2 EE 1.3 for Author Order 



Figure 19. Comparison of ES 1.0 and OS/2 EE 1.3 for Title Order 


Interface (SCSI) Tape Drive with 
Sytos Plus® File Backup Manager. 
For each run, the response time for 
each user was measured. 

Figure 22 shows the effects of 
archival logging on response time. 
Note that using a disk as the medium 
causes the least amount of degrada¬ 
tion, and the tape drive causes the 
most degradation. In all cases, the 
percent of degradation is fairly low. 

To evaluate the performance of for¬ 
ward recovery, NSTL’s Payment 
scenario with sixteen users was run 
for ten minutes. This produced about 
five log extents of 800 KB each. To 
perform forward recovery, the data¬ 
base was restored to the state before 
the run, then the archived log was 
“played back” so that it could be 
rolled forward. Total time was mea¬ 
sured using various media. Figure 23 
shows the total elapsed time for for¬ 
ward recovery. Recovery from disk 
takes the least amount of time, the 
Rewritable Optical Disk is a close 
second, and the tape drive takes much 
longer to complete this task. In gen¬ 
eral, the elapsed time of forward 
recovery depends on the size of the 
original database, the activities dur¬ 
ing the period of archival logging, 
and the medium used. 
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Figure 20. Comparison of ES 1.0 and OS/2 EE 1.3 for Payment 


Summary 

The benchmarks and test cases 
described in this article demonstrate 
the following key points: 

• The database design (such as the 
index structure) can dramatically 
affect the ES 1.0 Database Mana¬ 
ger performance. 

• Configuration parameters (such as 
buffer pool size) or communication 
protocol can affect performance. 

• If OS/2 2.0 is used, the Database 
Manager can take advantage of a 
system with more than 16 MB of 
memory, thus improving perfor¬ 
mance. 
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• With NSTL’s Book Order bench¬ 
mark, ES 1.0 with OS/2 2.0 consis¬ 
tently outperforms OS/2 EE 1.3. 

• The performance degradation due 
to archival logging seems reason¬ 
ably low. 

• The elapsed time for forward recov¬ 
ery depends on the medium used. 
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Figure 21. Comparison of ES 1.0 and OS/2 EE 1.3 for Shipment 



Figure 22. Effects of Archival Logging on Payment 
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Figure 23. Forward Recovery on Payment 
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AlertVIEW 

ShlomoTouboul 
Shany Computers, Ltd. 

Natanya, Israel 

AlertVIEW rM is the first network management solution for applications 
and operating systems. It is an application “sniffer” - that is, it looks into 
an application, gives network administrators information about the source 
of an error, and provides details about when and why it occurred. This 
article presents details about AlertVIEW. 


L ocal Area Networks (LANs), 
particularly token-ring net¬ 
works, are playing increasingly 
significant roles in large communica¬ 
tion networks. The most vital func¬ 
tion of a LAN - the very reason it 
exists - is to run applications and 
communication software. Without 
the ability to supervise and oversee 
these programs, they run with almost 
no control. As LANs increase in size 
and complexity, and as more applica¬ 
tions are downsized from mainframe 
computers to LANs, the need to man¬ 
age network applications from a 


central location becomes more pro¬ 
nounced. However, vendors of net¬ 
work management products have 
addressed network management only 
at the physical level - hubs, cables, 
bridges, and so on. No vendor has 
developed a solution for determining 
and resolving problems that occur 
within critical applications and Net¬ 
work Operating Systems (NOSs) - 
until now. 

The Solution: AlertVIEW 

AlertVIEW was created to bring criti¬ 
cal problems in applications and NOSs 


to the attention of the NetView® 
administrator at the enterprise level 
and the IBM Network LAN Manager 
(NLM). The NLM helps the LAN 
administrator manage the physical 
layer of the token ring at the LAN 
level. AlertVIEW adheres to IBM’s 
Systems Network Architecture (SNA); 
therefore NLM and NetView can 
receive alerts using IBM’s Network 
Management Vector Transport 
(NMVT), a protocol used in SNA to 
transport information. AlertVIEW 
also can send alerts to Novell’s Net¬ 
work Management System (NMS) 
using the Simple Network Manage¬ 
ment Protocol (SNMP). 

The seven-layer Open System Inter¬ 
face (OSI) model is a guideline that 
vendors use to ensure interoperability 
in the design of hardware and soft¬ 
ware. Within OSI, AlertVIEW pro¬ 
vides software alert management for 
the logical link level up to the appli¬ 
cation level. This completes a miss¬ 
ing piece of network management. 

AlertVIEW detects application, oper¬ 
ating system, and communication 
software problems when they occur. 

It permits heterogeneous networks, 
including bridges and gateways, to 
be viewed simultaneously at a single 
administrator’s station. This allevi¬ 
ates the need to have multiple work¬ 
stations for managing the network. 

AlertVIEW Overview 

AlertVIEW gives network adminis¬ 
trators a complete, unrestricted view 
of all facets of network application 
activities and failures. It provides a 
workstation agent that monitors appli¬ 
cation and operating system activities. 
This agent module, called AlertVIEW 
Station, detects application failures 
when they occur - before users are 
aware of problems. The AlertVIEW 
alert reports details about the work¬ 
station, application name, operating 
system resources (such as system ver¬ 
sion, memory, file name, directory 


Workstation 



Figure 1. AlertVIEW Agent and Console 
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name, disk sector number, and disk 
head and track), and network operat¬ 
ing system resources (such as file 
server name, queue name, and Inter¬ 
net® Packet Exchange/Sequenced 
Packet Exchange (IPX/SPX) socket 
number). 

Network administrators can configure 
AlertVIEW to provide an automatic 
response to predefined problems. 

This “trigger” ensures minimal dam¬ 
age and prevents problems from 
spreading. For example, an automatic 
trigger can occur when an electronic 
mail gateway fails to access a file 


and aborts. AlertVIEW can remotely 
restart the operation when the prob¬ 
lem is corrected. 

AlertVIEW Components 

AlertVIEW consists of several soft¬ 
ware components as shown in Figure 1. 

AlertVIEW Station (AVS): AVS is 
the agent loaded onto every DOS, 
Windows, or OS/2 workstation on 
the LAN. It detects software errors 
occurring on the workstation, and 
sends the alerts to IBM LAN Mana¬ 
ger, NLM, NMS, and the AlertVIEW 
Event Monitor (AVEM). Further¬ 


more, if the LAN Manager station is 
configured to be host-connected, then 
the NetView operator can receive 
critical alerts from the AlertVIEW 
stations. AVS is implemented as a 
DOS Terminate-and-Stay-Resident 
(TSR) program, a Windows Dynamic 
Link Library (DLL), or an OS/2 
device driver and process. 

The AVS can be configured to in¬ 
clude the AlertVIEW Application 
Programming Interface (API). All 
problems caused by the operating 
system’s failure to provide service to 
the application (such as an infinite 
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loop within the program, or bad logi¬ 
cal record contents when reading a 
file) are automatically reported by 
AVS to the management console. For 
more specific control, programmers 
can use the API to send logical alerts 
from the application and to monitor 
them the same way other software 
alerts are detected by AlertVIEW. 

This enables all applications on a 
station to send application-defined 
NMVT alerts to the IBM LAN 
Manager or AVEM. 

AlertVIEW OS/2 Server: This is 
the agent for OS/2 servers. It is imple¬ 
mented as a LAN service that detects 
when errors occur in applications run¬ 
ning on the OS/2 server, when criti¬ 
cal errors and traps occur in OS/2, 
and when available disk space reaches 
a predetermined level. The OS/2 
Server agent also receives any net¬ 
work alerts from the OS/2 file server 
and converts them into NMVT alerts. 

AlertVIEW Manager (AVM): This 
system management component 
remotely controls all AlertVIEW 
agents (AlertVIEW Station, Alert¬ 
VIEW Anti-Virus, AlertVIEW OS/2 
Server, and all future AlertVIEW 
agents). This component enables 
administrators to dynamically control 
all types of event filters, set up users, 
freeze or unfreeze workstations, and 
control workstation functions. The 
AVM software is loaded only onto 
the network administrator’s Windows 
or WIN-OS/2 workstation so that the 
AVS filters are set up according to 
users’ specific applications. 

AlertVIEW Event Monitor: AVEM 
is an OS/2 or enhanced Windows 
Multiple Document Interface (MDI) 
application designed to collect, dis¬ 
play, and automatically respond to all 
AlertVIEW and other IBM SNA 
alerts. An administrator can define 
Structured Query Language- (SQL-) 
like views, each displaying a different 
set of alerts (for example, a view of 


all alerts from a specific application, 
workstation, or segment). The admin¬ 
istrator also can predefine an auto¬ 
matic response - a trigger - for each 
specific alert. The trigger can modify 
the workstation’s CONFIG.SYS file, 
forward specific alerts into cc:Mail, 
or forward alerts from a remote site. 



AlertVIEW detects 
application, operating 
system, and 

communication software 
problems when they occur. 


Customization facilities enable set¬ 
ting up different fonts, colors, and 
sounds to any alert type or alert field 
to distinguish critical from non-criti- 
cal alerts. Because AVEM is a stan¬ 
dard SNA Event Monitor, IBM code 
point customization is also available. 

AlertVIEW SNA Gateway 
(AVGTY): AVGTY provides a 
means of transportation for alerts 
received by the AVEM from the 
AlertVIEW agents to the IBM host. 
NetView can monitor any application 
alert from the LAN, just as it does for 
mainframe applications. AVGTY is 
an OS/2 application that requires 
Digital Communications Associates 
(DCA®)/Microsoft Communication 
Server, IBM Communications Man¬ 
ager, or a compatible product. 

AlertVIEW Anti-Virus: This agent 
is loaded onto all workstations that 
require protection against viruses. It 
detects any attempt to infect the work¬ 
station and sends the appropriate 
alert to IBM LAN Manager, NLM, 
NMS, AVEM, or the NetView con¬ 
sole. Using AlertVIEW Anti-Virus 
with the AVEM, the network admin¬ 
istrator can set up automatic triggers 


that freeze, reboot, or disconnect a 
workstation that reports a virus infec¬ 
tion. This action automatically pre¬ 
vents the virus from spreading to 
other workstations and servers. 

Figure 2 shows how AlertVIEW 
modules interrelate. 

AlertVIEW Filtering 

AlertVIEW features extensive filter¬ 
ing and auto-blocking (“saturation”) 
management. Auto-blocking automat¬ 
ically prevents an alert from being 
sent over the network, because the 
software error has been determined 
to be insignificant. However, satura¬ 
tion values can be set so that the ad¬ 
ministrator is notified if this problem 
occurs a certain number of times 
during a specific period. 

Any software error situation is 
defined as an event. For a specific 
event, AlertVIEW can generate or 
disable (block) an alert. The ability to 
enable and disable software alerts is 
called alert filtering. The following 
filter types are available: 

• Unconditionally masked: Alert is 
unconditionally disabled. 

• Unmasked: Alert is unconditional¬ 
ly enabled (it will be generated). 

• Masked by counter: Alert will be 
generated only if the counter thres¬ 
hold (saturation level) is exceeded. 

• Masked by application name: 

Alert will be generated only if the 
alert is detected from an applica¬ 
tion that is specified. 

• Masked by logical name: Alert 
will be generated only if the alert 
is related to a specific file name, 
path name, server name, or queue 
name. 

Alert Saturation 

In a situation where an event is con¬ 
stantly repeated with no termination 
conditions, an infinite number of 


PERSONAL SYSTEMS / OCTOBER 1992 



83 


DOS 


Windows 


OS/2 



AVM: Management Console 
AVEM: Event Monitor 


AV SNA Gateway or 
IBM NLM or IBM LAN Manager 


Figure 2. AlertVIEW Modules 


software alerts will be sent to the 
administrator’s console, distracting 
the administrator’s attention from 
other critical alerts. The transmission 
of an alert ceases automatically if a 
predetermined counter (determined 
by either a time value, or a type of 
alert, or both) is not exceeded. 

The AlertVIEW filtering and satura¬ 
tion mechanism reduces the overhead 
of the network by reducing the num¬ 
ber of alerts, and permits concentra¬ 
tion on particular categories of 
problems. 


AlertVIEW Development 

AlertVIEW was created and devel¬ 
oped by Shany Computers Ltd, a soft¬ 
ware developer that specializes in 
support software for local area net¬ 
works. AlertVIEW was developed in 
cooperation with IBM, ensuring that 
every aspect of the program is fully 
compatible with NetView, IBM LAN 
Manager, and Network LAN Mana¬ 
ger. AlertVIEW is fully compatible 
with Institute of Electrical and Elec¬ 
tronics Engineers (IEEE®) 802.2, and 
has been designed to work with IBM 
LAN Server, Novell NetWare, Micro¬ 
soft LAN Manager, and Banyan® 
VINES®. 


Shlomo Tou boul, president of 
Shany and founder of the company 
in 1985, received his degree in 
computer science from Technion 
Polytech University in Haifa, 
Israel. 

Shany Computers Ltd. 

4 Smilansky Street 
Natanya, Israel 42432 
Phone (972)-53-626201 
Fax (972)-53-342418 

Shany, Inc. 

2680 Bay shore Parkway, Suite 104 
Mountain View, CA 94043 
(415) 694-7410 
Fax (415) 694-4728 
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Did You Know...? 


1 Advanced applications such as object-oriented programming, multimedia, 
and distributed computing require the versatility and reliability of OS/2 2.0. 


2 

3 


OS/2 2.0 is the first workstation operating system to fully exploit the features 
of the 386/486 family of processors. 


OS/2 2.0 runs Windows Versions 2.0 and 3.0 applications—something 
Windows 3.0 cannot do. OS/2 2.0 provides the broadest selection of appli¬ 
cations in the industry, running more than 20,000 DOS, 5,000 Windows, and 
2,500 16-bit OS/2 applications unchanged. 


OS/2 Systems Migration Considerations can help! 

OS/2 Systems Migration Considerations can help you take full advantage 
of the power of OS/2 2.0! The book provides detailed technical informa¬ 
tion about migrating to OS/2 2.0, Extended Services, and LAN Server 2.0 
environments. It also covers features of previous OS/2 versions and helps 
you locate them in 2.0, and describes features of Microsoft Windows 
included in 2.0. 

cr^er_ 



Send me_copies of OS/2 Systems Migration Considerations 

at $18.95* plus $3.95 shipping and handling, a total of $22.90** per copy. 

*Discounts available for multiple copies. 

**California residents add applicable sales tax. 


□ Charge to my VISA/MasterCard □ Check □ Money Order 


Name: _ 

Company: _ 

Address: _ 

City/State/Zip: _ 

Phone: _ 

VISA/MasterCard /:_ Expires: _/_ 

Make checks payable to: The TDA Group , P.O. Box 1360, Los Altos, CA 94023. 
For faster service, order toll-free by calling (800) 551-2832, or fax this form 
to (415) 948-4280. All orders must be prepaid. 


OS/2 is a registered trademark of the International Business Machines Corporation. 
Microsoft and Windows are registered trademarks of the Microsoft Corporation. 
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Screen Reader/2 

Ron Hoekzema and Kathleen Wahl Bode 
IBM Corporation 
Boca Raton, Florida 


Screen Reader 12™ is IBM's latest product for enabling computer use 
among users who are blind or who have visual disabilities. This article 
gives an overview of Screen Reader/2 and discusses several ways in which 
users - including those who do not have visual impairments - can make 
productive use of Screen Reader 12. The article also discusses the rest of 
the IBM Independence Series™ of products that assist people who have 
various kinds of impairments. 


f all the computer tools that 
convert screen information to 
speech, Screen Reader/2 is the 
first tool that makes IBM’s Graphical 
User Interface (GUI) available to 
users who are blind or have visual 
disabilities. Screen Reader/2 enables 
people with visual impairments to 
enjoy the power and productivity af¬ 
forded by IBM’s GUI and the multi¬ 
tasking capability of OS/2 2.0. 

In 1988, IBM’s Special Needs Sys¬ 
tems group announced its first DOS- 
based product. Screen Reader 1.0. 
This product converted computer 
screen text to voice through the use of 
voice synthesis. Since then, the tech¬ 
nology and applications have pro¬ 
gressed to GUIs, such as IBM’s OS/2. 

Verbalizing the OS/2 2.0 GUI 

Screen Reader/2 runs under OS/2 
2.0. It provides voice output of all 
OS/2 screen information, including 
error and status messages. Screen 
Reader/2 recognizes and verbalizes 
the many icons and objects in OS/2 
2.0. It functions in all sessions of 
OS/2, including DOS and Windows 
sessions. 


Screen Reader/2 provides many 
things that sighted users take for 
granted. For example, when a user 
selects “File” from an action bar, a 
menu is presented. Each item in the 
menu has one underscored letter, 
such as O in Open or H in Help. If 
the user presses the “O” key, the 
Open command is executed. Screen 
Reader/2 tells the user what the 
underscored letters are, thereby assist¬ 
ing users with visual disabilities. 

By remembering which letters are 
underscored, the user can increase 
productivity by bypassing the spoken 
explanation of what is in the menu. 

In Screen Reader/2, the user can cre¬ 
ate a fast path from task to task. For 
example, assume that under OS/2 2.0 
the user is running an emulator, a 
spreadsheet application, and a word 
processor application. Each one can 
be given an identifier (such as 1 or 2) 
that can be keyed in on the special 
18-key keypad. When the user keys 
the identifier, the selected application 
becomes the active screen. 

Following the Visual Focus 

This product follows the visual focus 
- what a sighted person’s eyes are 
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actually following on the display 
screen - and reads the text or the con¬ 
trols (such as pushbuttons) automati¬ 
cally. It alerts the user when changes 
occur - for example, when the status 
message “Mail Waiting” appears in 
the host emulation session. While 
browsing through a document, the user 
can read the entire screen, selected 
lines, or selected words. Words can 
be spelled out audibly, and keystrokes 
can be heard as they are typed. 

Users should have little difficulty 
installing and using Screen Reader/2. 
Installation instructions are provided 
on audio cassette, in print, and in 
Braille. A complete Screen Reader/2 
tutorial also is provided online. It is 
similar to the powerful OS/2 online 
documentation facility. Although 
knowledge of OS/2 and related soft¬ 
ware applications is helpful, a person 
familiar with using computers under 
DOS should easily be able to use 
Screen Reader/2 in the OS/2 
environment. 

Other Uses for Screen 
Reader/2 

There are an estimated 11 million 
people with visual disabilities in the 
United States. Screen Reader/2 was 
developed primarily to open doors 
for them and others worldwide. How¬ 
ever, Screen Reader/2 also can be 
used by sighted people in environ¬ 
ments where they can “read” the 
screen in conjunction with perform¬ 
ing another task. For example, in a 
training environment, a user may 
look at an assembly or component 
and perform an operation while lis¬ 
tening to instructions spoken by 
Screen Reader/2. Screen Reader/2 
also can be an aid to people who 
have reading impairments. 
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The Screen Reader/2 product 

includes the following components: 

• Software 

• A separate 18-key keypad for 
entering user commands 

• 3.5-inch and 1.44 MB diskettes that 
include the online documentation 

• Installation instructions (audio 
cassette, print, and Braille) 


• Raised images of the icons in 
OS/2 2.0 screens to complement 
the online tutorial 

Screen Reader/2 requires OS/2 2.0 
and at least 2 MB of hard disk space. 
A commercially available text-to- 
speech synthesizer is also required. 

IBM Independence Series 

IBM Screen Reader/2 is one of the 
products in the IBM Independence 


Series. The Independence Series 
products, which are PS/2-based, pro¬ 
vide IBM technology to enhance the 
employability and quality of life of 
people who have disabilities. These 
products are now even more signifi¬ 
cant because of the Americans with 
Disabilities Act that went into effect 
this year. This act requires that 
employers not discriminate against 
people with disabilities, and that 
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employers provide reasonable job 
accommodations for them. 

Independence Series products are 
available for persons with vision, 
hearing, mobility, speech, or 
cognitive disabilities. 

Assistive Accommodations 

A new DOS-based version of Screen 
Reader, IBM Screen Reader/DOS 
1.2, enables people who are blind or 
have visual disabilities to use a com¬ 
puter as a sighted person would. 
Screen Reader is a software program 
that converts screen text to speech, so 
that a user can hear the words on a 
computer screen and can do word 
processing, computer programming, 
and other computer tasks. 

IBM PhoneCommunicator™ allows 
people with hearing or speech impair¬ 
ments to communicate with others 
who are calling via a standard touch- 
tone telephone or a Telecommunica¬ 
tion Device for the Deaf (TDD). It 
even provides a full-screen view of 
the dialog of both parties. 

Until now, the ability to use a key¬ 
board was essential for operating 
computers. Now you can use your 
voice to operate a computer. IBM 
VoiceType™ is a DOS-based pro¬ 
gram for voice-controlled access to, 
and use of, many text-based pro¬ 
grams, including word processors 
and business applications. Voice- 
Type has a vocabulary of over 7,000 
words and is a significant produc¬ 
tivity enhancement for persons with 
upper mobility impairments. 


The IBM KeyGuard is a template to 
enhance keying accuracy on an IBM 
Enhanced Keyboard or IBM Space 
Saving Keyboard on PS/2s, AS/400s, 
RISC System/6000s™, and various 
IBM terminals. The KeyGuard is a 
molded keyboard overlay with holes 
that expose and isolate each keytop. 

It is appropriate for use by persons 
with mobility impairments and palsied 
conditions, and in education and pre¬ 
school environments, to enhance 
keyboarding accuracy. 

AccessDOS is an IBM utility that 
improves and expands access to 
DOS. It provides extended keyboard, 
mouse, and sound access on a com¬ 
puter, including StickyKeys, Mouse- 
Keys, RepeatKeys, ToggleKeys, and 
ShowSounds - all important features 
for people whose mobility is impaired. 
AccessDOS is available at no charge. 

Clinical Solutions 

Designed to increase the efficiency 
of speech therapy, IBM Speech- 
Viewer™ and IBM SpeechViewer II 
use the power of the IBM PS/2 to 
convert elements of speech acoustics 
to interactive graphic displays that 
are synchronized with audio playback. 
DOS-based SpeechViewer includes 
modules to help develop basic aware¬ 
ness and skill building of selected 
aspects of speech. SpeechViewer II 
is DOS- or OS/2-based and includes 
more advanced modules. 

IBM THINKable™ is an OS/2-based 
clinical tool for computer-assisted 
cognitive remediation therapy and 
for attention and memory practice. 
THINKable provides clinical profes¬ 
sionals with an exciting way to offer 


skills practice to clients with cogni¬ 
tive disabilities and to enhance case 
management. THINKable uses color¬ 
ful, photo-realistic pictures and real 
speech to help clients practice skills 
in four critical focus areas: visual at¬ 
tention, visual discrimination, visual 
memory, and visual sequential 
memory. 

To obtain a brochure about the IBM 
Independence Series, order G520- 
9070; for a videotape about the Inde¬ 
pendence Series, order GV21-9070. 


Ron Hoekzema is a senior mar¬ 
keting programs administrator in 
the IBM Entry Systems Technol¬ 
ogy laboratory in Boca Raton , 
Florida. Ron has held several 
engineering and engineering man¬ 
agement positions and product 
planning and planning manage¬ 
ment positions in both hardware 
and software organizations. He is 
currently in Special Needs Sys¬ 
tems as the marketing programs 
administrator for Screen Reader! 
DOS 1.2 and Screen Reader 12. 

Kathleen Wahl Bode is a senior 
marketing programs adminis¬ 
trator in the IBM Entry Systems 
Technology laboratory in Boca 
Raton, Florida. She joined IBM in 
1972 as part of its Science Re¬ 
search Associates subsidiary in 
Chicago. Kathy is currently the 
Special Needs Systems marketing 
programs administrator for PS/2- 
hased products for persons with 
mobility impairments , including 
VoiceType , AccessDOS , and the 
KeyGuard. 
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Little Solutions 



We invite you to share your “ little solutions' in 
this column. Send them to us in care of the editor. 


Icon Editing 

hen editing or changing an 
icon in OS/2 2.0, be aware of 
the icon’s bitmap format in 
OS/2. The following describes the 
procedure for modifying an icon. 

With the right mouse button, choose 
the icon you want to edit. In the dis¬ 
played menu, use the left mouse but¬ 
ton to select the little arrow next to 
Open, then select Settings from the 
next menu. Select the General page 
from the displayed notebook. Select 
the Edit pushbutton. The icon editor 
is now invoked with the current icon 
of the chosen object. From the icon 
editor’s menu, select Device, then 
select List from the drop-down menu. 
A list of bitmap types will be displayed. 

Bitmaps are the operating system’s 
representation of the icons that you 
see. Each bitmap file can contain 


many bitmap formats that are used 
for different displays and purposes. 
Figure 1 lists all the icon bitmap for¬ 
mats used in OS/2. For example, if 
you want to change the Desktop icon 
and you are using a VGA display, 
select the Independent Color Form 
(VGA) format. 

After making your changes, go to the 
icon editor’s menu. Select File, then 
select Save from the drop-down 
menu. Your Desktop icon should 
now be changed. 


Sorting Out SCSI Adapters 

T here are differences among the 
redesigned Small Computer Sys¬ 
tems Interface (SCSI) adapters 
being shipped in PS/2 Models 90 and 
95. The differences and a discussion 
of how to distinguish among these 
adapters follow. 

IBM markets two types of PS/2 
Micro Channel SCSI adapters: one 
with cache and one without cache. 
There are two versions of the PS/2 
Micro Channel SCSI Adapter with 
Cache: a new one (part number 
6451133, feature code 1132) and the 
old one (part number 6451110, fea¬ 
ture code 1018). The 50 MHz models 
of the PS/2 Models 90 and 95 are 
shipped with the new SCSI Adapter 
with Cache. There is only one ver¬ 
sion of the PS/2 Micro Channel SCSI 
Adapter without cache (part number 
6451109, feature code 1005). 

To work properly, a SCSI bus must 
be terminated on both the internal 
and external ends of the bus. The 
SCSI Adapter without cache and the 
new SCSI Adapter with Cache each 
have a terminator as part of the 
adapter. This terminator is a reddish 
orange resistor located on the top 
next to the connector end of the 
adapter. 

This terminator can be used to ter¬ 
minate either end of the bus. If there 
are no external devices on the bus, 
the terminator becomes the external 
bus terminator. If there are no inter- 


Icon Form 

Used By 

Independent Color Form (VGA) 

OS/2 Desktop for VGA displays 

8514 (16 colors) 

OS/2 Desktop for XGA and 8514/A displays 

1 Bit/Pixel (Independent) 

System icon (the little one in the upper left 

16 x 16, 0 x 0, 0 x 0 

comer) for VGA displays 

1 Bit/Pixel 

20 x 20, 1024 x 768, 0x0 

System icon for XGA and 8514/A displays 


Figure 1. Changing the Desktop Icon 
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nal devices on the bus, the terminator 
is used as the internal bus terminator. 
If both internal and external devices 
are on the bus, the terminator must be 
removed. The last device on both 
ends of the bus also must be termi¬ 
nated with another type of terminator. 
(Refer to the SCSI device installation 
instructions for more information.) 

The old SCSI Adapter with Cache 
does not have this built-in terminator. 
It must be terminated differently. If 
there are no external devices installed, 
a 60-pin external terminator (part 


number 6451039, feature code 1039) 
must be used. If there are no internal 
devices installed, a 50-pin terminator 
(part number 33F8724), which comes 
with the adapter, must be installed on 
the top edge of the SCSI adapter. If 
both internal and external devices are 
installed, a terminator must be in¬ 
stalled on the last device on each end 
of the bus. (Refer to the SCSI device 
installation instructions for more 
information.) 

You can distinguish between all 
these adapters by looking at them. If 


the adapter has no SIMM sockets at 
the upper left end, it is a PS/2 Micro 
Channel SCSI Adapter without cache. 
If it has SIMM sockets, it is a SCSI 
Adapter with Cache. If it is a SCSI 
Adapter with Cache and it has the 
reddish orange resistor at the upper 
left comer, it is the new SCSI Adapter 
with Cache. If it is a SCSI Adapter 
with Cache but the reddish orange 
resistor is not there, it is the old SCSI 
Adapter with Cache. 

— Chuck Hanford , IBM 
Corporation , Dallas , Texas 


Book Reviews 

The COBOL Presentation 
Manager Programming Guide 

One of the current paradigms in per¬ 
sonal computer programming is that 
C language is the only programming 
language that fully supports OS/2 
and the Presentation Manager (PM). 
The theory that OS/2 and PM pro¬ 
gramming languages are limited to 
Macro Assembler or C may have 
been true historically, but today the 
correct COBOL compiler can pro¬ 
vide as much support for OS/2 or PM 
as any C compiler. The availability 
of reentrant COBOL compilers, such 
as the Micro Focus COBOL/2® com¬ 
piler, allows COBOL programmers 
to implement the most sophisticated 
of PM programs while maintaining 
the familiar, easy-to-understand, 
source code format that they know. 

There remains, however, a significant 
roadblock for COBOL programmers 
venturing into PM programming. The 
lack of COBOL-oriented, technical 
documentation can slow or even halt 
the otherwise successful develop¬ 
ment of COBOL PM applications. 
Among the volume of OS/2 and PM 
programming materials, including 
the materials available from IBM, 


there is none that support program¬ 
ming of the Presentation Manager in 
COBOL. Indeed, within the flood of 
PM “how-to” programming books, 
there are none that teach COBOL 
programmers “how-to.” 

But, with the recent availability of 
The COBOL PM Programming Guide , 
the lack of technical documentation 
has begun to disappear. This book is 
a combined “how-to” and technical 
reference book for PM programming, 
written in COBOL, expressly for use 
by COBOL programmers. 

While providing COBOL program¬ 
mers with a “fast path” to their first 
PM window, this first-of-its-kind ref¬ 
erence book is also an excellent tool 
for programmers to begin their PM 
programming training, regardless of 
their language specialty. Assuming 
no prior OS/2 or PM knowledge, the 
book begins with a complete explana¬ 
tion of the OS/2 and PM environments, 
moves on to list specific changes that 
must be made to traditional COBOL 
structured programs when writing 
COBOL PM programs, and finally 
details how to set up a COBOL PM 
development environment. 

Following these introductory topics, 
The COBOL PM Programming 
Guide lays out, in step-by-step chap¬ 


ters, how to code both the basic PM 
program and more advanced features 
such as user dialogs, creating text and 
graphical output, window subclass¬ 
ing, dynamic linking, multithreading, 
and device-independent printing. 

Special attention has been given to 
the changes in the traditional COBOL 
structured programming that program¬ 
mers face when writing PM programs. 
The book begins with a discussion of 
the unique requirements placed on 
programs by the PM environment. It 
details the changes in standard 
COBOL coding that PM requires - 
everything from the reversed order 
of the calling stack to how to write 
reentrant code procedures. For each 
change required to the traditional 
structured coding, the book describes 
the specific code to solve the problem. 

While The COBOL PM Program¬ 
ming Guide is designed as a teaching 
manual, it also serves as a technical 
reference manual for COBOL pro¬ 
grammers. Its appendices contain 
definitions required in every PM pro¬ 
gram, some of which cannot be found 
in any other document. The technical 
references include the following: 

• Over 70 pages of sample COBOL 
PM code 
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• A skeletal COBOL PM program 
to form the nucleus of every PM 
program that is written 

• An appendix of the most common 
PM calls coded in COBOL 

• The numerical definitions of over 
2,500 PM messages and variables 
that compose the OS/2 Version 2.0 
C header files 

• A chart of the 16-bit OS/2 and PM 
calls, showing how each must 
change when moving to a 32-bit 
compiler 

By closing the gap in PM’s technical 
documentation, The COBOL PM 
Programming Guide has moved 
COBOL further along the path toward 


a fully supported PM programming 
language, and the ability to program 
PM applications in COBOL can dras¬ 
tically alter the cost equation for a 
conversion to PM. The traditional 
COBOL programming shops that 
cannot justify the move based upon a 
simultaneous conversion to C and 
PM can now take another look at the 
cost and time involved without a C 
language conversion. 

The author, Dave Dill (817 491-2147), 
provides consulting and education 
for OS/2 and Micro Focus® COBOL 
for Presentation Manager. Dave 
worked for IBM for over 23 years, 
most recently in customer support, 
specializing in installations and usage 



David M. Dill 


The 


COBOL Presentation Manager 
Programming Guide 
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support for PCs. For the past four 
years, he provided technical support 
for the OS/2 Standard Edition operat¬ 
ing system, including the OS/2 ker¬ 
nel, Presentation Manager, the OS/2 
printing subsystem, the programming 
toolkit, and COBOL programming 
under OS/2 and Presentation Mana¬ 
ger. Dave was a frequent contributor 
and technical consultant for IBM Per¬ 
sonal Systems Technical Solutions 
magazine. 

Dill, David M. The COBOL Presenta¬ 
tion Manager Programming Guide. 
Van Nostrand Reinhold: 1992. ISBN 
0-442-01293-4. Available from Micro 
Focus Publishing (800) 551-5269. 

IBM form number G362-0010. 

Client/Server Programming 
with OS/2 2.0 (Second Edition) 

Building on the best-selling original 
edition’s strengths, the second edi¬ 
tion of Client/Server Programming 
with OS/2 2.0 contains over 600 new 
pages on advanced client/server tech¬ 
nology and OS/2 2.0 features. Through 
easy-to-read, in-depth tutorials and 
working code, the book shows how 
to integrate databases, LANs, and 
Workplace Shell clients to build cli¬ 
ent/server applications using OS/2 2.0. 

The book is written in a friendly style 
- 100 new cartoons and illustrations - 
that will appeal to a wide audience 
ranging from novices to PC program¬ 
mers and MIS professionals. It also 
should be of great interest to LAN 
and communications specialists, data¬ 
base administrators, and anyone with 
a general interest in client/server tech¬ 
nology or OS/2 2.0. 

The first 200 pages are virtually a 
book within a book. Written with 
mere mortals in mind, this section 
provides a complete introduction to 
OS/2 2.0 features, how OS/2 2.0 com¬ 
pares to other client/server platforms 
(Windows 3.X, UNIX, NT, and Net¬ 
Ware), and OS/2-based client/server 
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Robert Orfali 
Dan Harkey 


Client/Server 

Programming with 

OS/2.2.0 


2 nd ED. 



products—including MMPM/2, Data¬ 
base Manager, DDCS/2, Communica¬ 
tions Manager, TCP/IP for OS/2, 

LAN Server, and NetWare Requester 
for OS/2 2.0. The authors also pro¬ 
vide a useful overview of client/server 
architecture including DCE, multiser¬ 
vers, open systems, and Systems 
Application Architecture (SAA). 

This section makes great reading for 
anyone with a general interest in 
OS/2 2.0 or client/server technology. 

The remaining 900 pages are a pro¬ 
grammer’s paradise. They cover 
almost every aspect of programming 
the OS/2 2.0 client/server platform. 
The book includes 300 pages of 
working code using the new 32-bit C 
Set/2 compiler. All the code is ac¬ 
companied by detailed tutorials that 
explain the concepts first. Here’s a 
brief overview of the programming 
topics covered: 

• OS/2 2.0’s core services - includ¬ 
ing threads, 32-bit semaphores, 
and Named Pipes (200 pages). 

• OS/2 2.0’s LAN client/server com¬ 
munications, including CPI-C over 
APPC, NetBIOS, Named Pipes, 
Sockets over TCP/IP, NetWare, 
and LAN Server. To make this 
hard topic fun, the authors stage a 
BLOB Olympics that compare the 
performance of these popular 
protocols (160 pages). 

• LAN-based SQL transaction ser¬ 
vers using the Extended Services 
Database Manager and DDCS/2. 
This includes a detailed introduc¬ 
tion to these two database prod¬ 
ucts and to SQL programming. 

The authors show how to create 
transaction servers on an OS/2 
platform. They use the TP1 bench¬ 
mark to demonstrate the many 
trade-offs in client/server design. 
Which should you use: Static SQL 
or Dynamic SQL? Remote SQL or 
Stored Procedures? Transaction 
Servers or Database Servers? Fat 
clients or fat servers? You’ll know 


after reading this section (330 
pages). 

• Object-Oriented User Interfaces 
(OOUIs) using PM, SOM, and the 
Workplace Shell class libraries. 
The authors explain the benefits of 
OOUIs and how they can be used 
to create client frontends. They 
bring the point home by creating a 
complete client/server application 
- a Club Med reservation system. 
The flamboyant Club Med front- 
end is created using new objects 
derived from SOM/WPS classes. 
The backend uses a transaction 
server built on top of the OS/2 
Database Manager (220 pages). 

The book can be used as a supple¬ 
mentary text for courses on OS/2 2.0, 


networks, operating systems, Online 
Transaction Processing (OLTP), 
LANs, SQL, database theory, OOUIs, 
and client/server systems. Finally, 
this is the definitive book for anyone 
who needs to understand the power 
OS/2 2.0 offers today as both a client 
and server platform. 

Orfali, Robert and Harkey, Dan. 
Client/Server Programming with 
OS/2 2.0 (Second Edition). Van 
Nostrand Reinhold: 1992. ISBN: 
0-442-01219-5. Available at local 
bookstores and from the publisher 
(800) 842-3636. 

IBM form number G325-0650. 
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New Products 


IBM PS/note Model N45 SL 
Notebook Computer 

The IBM PS/note Model N45 SL is a 
high-performance, lightweight, battery- 
operated (AC/DC) notebook PC. 
Standard features include a 25 MHz 
80386 SL processor with 64 KB 
cache, 2 MB of 80 ns memory 
(expandable to 8 MB), 2.5-inch 80 
MB or 120 MB hard disk, 3.5-inch 
1.44 MB diskette drive, 10-inch 32 
grayscale Video Graphics Array 
(VGA) resolution LCD, 82/83-key 
keyboard, serial port, parallel port, 
keyboard/mouse port, external VGA 
port, rechargeable battery pack, and 
AC adapter. 

Also announced as options for the 
IBM PS/note Model N45 SL are 
2 MB RAM, 2400 baud data modem, 
international fax/data modem (2400 
baud data, 9600 baud fax), IBM 
PS/note NiCd Battery for Model N45 
SL with a battery cradle for quick 
charging, PS/2 miniature mouse, and 
the IBM PS/note AC Adapter for 
Model N45 SL. The PS/note carrying 
case is available as an accessory. 

International Hardware Warranty Ser¬ 
vice is offered for users who travel 
worldwide to countries where this 
product is sold by IBM, IBM Author¬ 
ized Personal Computer Dealers, or 
IBM Authorized Industry 
Remarketers. 

Highlights: 

• Large, clear, and vivid liquid 
crystal display 

• A high-performance processor 
(25 MHz 80386 SL), expandable 
memory (2 MB to 8 MB), large 


hard disk (80 MB or 120 MB), and 
long battery life 

• Rugged, soft-touch, and scratch- 
resistant finish 

Letter # 192-162, July 21,1992 

IBM PS/2 Model 57 SLC 

PS/2 Model 57 SLC complements 
and enhances the PS/2 family of 
Micro Channel systems with the inte¬ 
gration of the IBM 386 SLC 20 MHz 
microprocessor that includes 8 KB of 
internal cache and the internal cache 
controller. Also included are a high- 
performance, large hard disk; a 2.88 
MB media sense diskette drive; a 16- 
bit VGA adapter; a Small Computer 
Systems Interface (SCSI); and 8 MB 
of memory housed in the same ver¬ 
satile 5-slot/4-bay mechanical pack¬ 
age as other IBM PS/2 57 SX and 57 
SLC systems. Model 57 SLC is of¬ 
fered with a disk capacity of 400 MB. 

The system allows horizontal or verti¬ 
cal operation and ships with a stand 
for the vertical orientation. Five 16- 
bit Micro Channel slots allow users 
to expand and customize system func¬ 
tions. A hard disk and diskette drive 
are installed in each system, and two 
expansion bays are available to accept 
additional 5.25-inch and 3.5-inch 
diskette drives, hard disks, tape, CD- 
ROM, or other devices. The SCSI 
controller is integrated into the planar, 
so no slot is required to attach up to 
seven SCSI devices (including the 
standard hard disk). Two additional 
SCSI devices can be installed inter¬ 
nally and the remainder externally 
with the external connector. 

PS/2 Model 57 SLC comes with two 
4 MB, 70 ns Single In-Line Memory 


Modules (SIMMs) and allows instal¬ 
lation up to a total of 16 MB of 70 ns 
memory on the planar. The memory 
controller automatically supports 
enhanced performance through mem¬ 
ory interleaving with appropriate 
memory configurations. The standard 
video for the PS/2 Model 57 SLC is 
16-bit VGA. 

The IBM PS/2 Model 57 SLC sup¬ 
ports the IBM Enhanced Keyboard 
(101-key), Space Saving Keyboard 
(84-key), IBM Host-Connected 
Keyboard (122-key), and a variety of 
languages. 

Letter #192-177, August 11,1992 

IBM PS/2 486DX2-66 Processor 
Upgrade Option 

The IBM PS/2 486DX2-66 Processor 
Upgrade Option enhances the PS/2 
Model 90 XP 486 and Model 95 XP 
486 system families. This new upgrade 
option and its Intel 486DX2-66 micro¬ 
processor provide the capability to 
upgrade processor performance on 
the PS/2 Model 90 XP 486 and 
Model 95 XP 486 systems. 

The 486DX2-66 microprocessor 
operates at an internal clock speed of 
66 MHz and an external speed of 33 
MHz. It includes an internal memory 
cache controller, 8 KB memory cache, 
and an integrated floating-point proc¬ 
essor unit. Additionally, the proces¬ 
sor complex supports the external 
PS/2 256 KB Level 2 Cache Option. 

The 486DX2-66 Processor Upgrade 
Option significantly increases system 
processor performance in compute¬ 
intensive applications, providing 
investment protection to owners of 
lower performance models of the 
PS/2 Model 90 XP 486 and Model 95 
XP 486 systems. 

Letter# 192-178, August 11, 1992 
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IBM PS/2 8511 Color Display 
Model 001 

The PS/2 8511 Color Display Model 
001 is a 14-inch, medium-resolution 
VGA color display with smaller dot 
pitch and sharper characters relative 
to the IBM PS/2 8512 Color Display. 
The 8511 Color Display, a derivative 
of the 8518 Color Display, is a suit¬ 
able display for VGA users. The low 
emissions standards. Extremely Low 
Frequency Magnetic Field (ELMF), 
and Very Low Frequency Magnetic 
Field (VLMF) are in response to user 
requests and emerging international 
requirements. 

Letter# 192-180, August 11,1992 

IBM 4070 IJ Printer 

The IBM 4070 IJ Printer is a small, 
letter-quality, ink-jet printer designed 
as a low-usage, personal desktop 
printer. The 4070 IJ prints at up to 83 
characters per second (cps) in letter- 
quality mode and up to 110 cps in 
high-speed mode on plain paper at a 
quiet 45 dBA level. 

There are two models of the 4070 IJ: 
Model 001 includes a 50-sheet Auto¬ 
matic Sheet Feeder (ASF), and Model 
002 offers the ASF as an option. An 
optional battery pack is available for 
both models. 

Letter# 192-176, August 11,1992 

Selected IBM PS/2 Models Upgraded 
to 8 MB of Standard Memory 

IBM has enhanced standard system 
memory to 8 MB on PS/2 Model 56 
SLC, Model 57 SLC, and Model 
M57 SLC systems. With this change, 
all enhanced systems have double the 
standard system memory to better 
address user application requirements. 

The PS/2 Model 56 SLC, Model 57 
SLC, and Model M57 SLC systems 
include OS/2 2.0. A 160 MB hard 
disk and OS/2 2.0 combine for a func¬ 
tionally adaptive, high-performance 


desktop system with a hardware plat¬ 
form conducive to solutions for a 
range of user requirements. 

These selected systems are shipped 
with two 4 MB, 70 ns SIMMs and 
allow up to 16 MB 70 ns memory on 
the planar. The memory controller 
automatically supports enhanced per¬ 
formance through memory interleav¬ 
ing with the appropriate memory 
configurations. 

Letter # 192-165, July 21, 1992 

IBM PS/2 Micro Channel to 
Mainframe Connection 

The IBM PS/2 Micro Channel to Main¬ 
frame Connection, when used with 
appropriate software, enables users to 
connect an IBM Micro Channel PS/2 
directly to a System/370™, Sys- 
tem/390®, ES/3090™, or ES/9000™ 
channel running in block-multiplexer 
mode. Since no communications pro¬ 
tocol is involved, the transfer of data 
between the two systems can be up to 
4.5 MB per second. 

Attachment to ESCON™ channels is 
supported by the IBM 9034 ESCON 
Converter Model 1. This adapter 
replaces the IBM PS/2 System/370 
Channel Adapter. 

Highlights: 

• Intelligent adapter with onboard 
microprocessor and data buffers. 

• Up to two Micro Channel-to- 
Mainframe Connection adapters 
can be installed in a single PS/2 
computer. 

• Up to three Micro Channel-to- 
Mainframe Connection adapters 
can be daisy-chained on the same 
host system channel. 

Letter # 192-156, June 30, 1992 

IBM 5183 Portable Printer 

The IBM 5183 Portable Printer is a 
compact, letter-quality, plain paper. 


thermal transfer printer designed to 
fit in a briefcase along with a laptop 
or notebook computer. The printer is 
battery-powered and prints in letter- 
quality at up to 53 characters per 
second. 

Highlights: 

• Lightweight (only 2.5 pounds) 

• Letter-quality printing 

• Eight-inch print line across page 

• Battery-powered operation 

• Standard paper or transparencies 

• 4 KB integrated buffer 
Letter # 192-167, July 28,1992 

LAN Connection for Printers in 
Novell NetWare Environment 

The IBM LAN Connection for 
Printers and Plotters provides a direct 
connection of parallel and RS232C 
serial printers and plotters to Local 
Area Networks (LANs). These sup¬ 
port Novell NetWare networks. The 
IBM LAN Connection for Printers 
and Plotters consists of a network 
printer adapter unit that attaches to a 
LAN, and a software utility that 
resides on the LAN print server. The 
adapter unit has both a serial and a 
parallel port that can be used simul¬ 
taneously to support two printers or a 
printer and a plotter. 

The software utility takes the print 
data normally sent to the print server’s 
parallel ports and redirects it to either 
the parallel or serial port of the adapt¬ 
er. The appropriate printer attached 
to the adapter receives the data and 
prints it just as if the printer were 
attached to the server’s printer port. 

The IBM LAN Connection for 
Printers and Plotters software utility 
supports remote printing in PSERVER 
or RPRINTER mode with Novell 
NetWare 2.2 or 3.11 connected to 
either a Token-Ring (IEEE 802.5) or 
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an Ethernet (IEEE 802.3 or Ethernet 
II) LAN. 

The IBM LAN Connection for 
Printers and Plotters operates without 
noticeable degradation of printing 
performance and supports the fol¬ 
lowing data streams: IBM Personal 
Printer Data Stream (PPDS), Hewlett- 
Packard® Printer Control Language 
(HP PCL), IBM/HP Graphics Library 
(GL), and Adobe PostScript®. A 
friendly interface allows users to 
easily configure and maintain one or 
more adapters on a network. 

Highlights: 

• PSERVER and RPRINTER 
support is provided. 

• The 4033 provides simultaneous 
support for connecting printers or 
plotters: 

— One parallel printer 

— One RS232C serial printer or 
plotter port 

• The 4033 Model 011 provides 
support for Token-Ring 4/16 
Mbits/second data rate (IEEE 
802.5). 

• The 4033 Model 012 provides 
support for Ethernet lOBaseT 10 
Mbits/second data rate (IEEE 
802.3). 

• The 4033 Model 013 provides 
support for Ethernet 10Base2 and 
10Base5 10 Mbits/second data rate 
(IEEE 802.3 or Ethernet II). 

• Printers and plotters can be located 
in user work areas, which can be 
remote from the print server. 

• Eight file servers, two preferred 
file servers, and thirty-two print 
queues are supported. 

• The 4033 is compatible with IBM 
PPDS, Adobe PostScript, HP® 

PCL, and IBM/HP GL. 

Letter # 192-173, July 28,1992 


IBM PS/2 Adapter/A for Ethernet 
Twisted-Pair Networks 

IBM enhances its LAN family of 
products by announcing the Personal 
System/2 Adapter/A for Ethernet 
twisted-pair networks. This LAN 
adapter provides the ability to attach 
PS/2 Micro Channel bus systems to 
Ethernet networks. The adapter sup¬ 
ports Ethernet Version 2 and IEEE 
802.3 CSMA/CD with data transfers 
at 10 Mbits/second through an 
Attachment Unit Interface (AUI) or 
RJ45 connector. Connection to 
lOBaseT (unshielded twisted-pair 
cable) is provided through the RJ45 
connector. Connection to 10Base2 
(thin coaxial cable) or 10Base5 (thick 
coaxial cable) is provided through the 
AUI connector and a user-provided 
external transceiver. Remote Pro¬ 
gram Load (RPL) is included as stan¬ 
dard for systems requiring RPL 
capability. 

Highlights: 

• Offers both Ethernet and token¬ 
ring products to create intelligent 
LANs 

• Allows Ethemet/802.3 users to 
expand networks 

• Supports multiple interfaces and 
LAN software 

• Supports Ethernet Version 2 and 
IEEE 802.3 CSMA/CD interfaces 

• Provides an easy-to-use interface 
for installation and setup, configu¬ 
ration and diagnostic capabilities, 
and maintenance 

Letter # 192-158, June 30,1992 

LAN Automated Distribution/2 Service 

LAN Automated Distribution/2 
(LAD/2) Service, a system-engineer- 
delivered billable service, enables the 
installation and configuration of OS/2 
2.0, OS/2 EE 1.3, and DOS from a 
distribution server to PS/2s on IBM 
Token-Ring and Ethernet LANs. 


With LAD/2, you also can migrate 
from: 

• OS/2 1.2 or 1.3 to OS/2 2.0 (Base) 

• IBM DOS 3.3 and above or DOS 
with Windows to OS/2 2.0 

• OS/2 EE 1.2 to OS/2 EE 1.30.2 

• IBM DOS to Dual Boot 

IBM system engineers who have been 
qualified on LAD/2 can perform a 
billable service for users who want to 
install/distribute the following: 

• IBM OS/2 2.0 

• IBM Extended Services 

• IBM LAN Server 2.0 (LAN 
Requester only) 

• IBM OS/2 Extended Edition 1.30.2 

• IBM DOS 5.0 

• IBM Personal Communica¬ 
tions/3270 

• IBM LAN Support Program 

• IBM DOS LAN Requester 

• IBM DOS Database Requester 

• Microsoft Windows 

• Novell NetWare Requester 

• OS/2, DOS, Windows, and user- 
developed application software 

For more information about this 
service, call (800) 547-1283. 

IBM Education LAN and Tools 386 

IBM Education LAN and Tools 386 
(EdLAN 386) is an education network 
package of network software, produc¬ 
tivity tools, and related publications. 
The network software includes IBM 
Classroom LAN Administration Sys¬ 
tem Version 1.40 and NetWare from 
IBM V3.11. The productivity tools 
consist of: 

• LinkWay™ Version 2.01 

• Microsoft Works Version 2.0A 

• LANSchool® Version 3.2 
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• Excelsior grade2 Version 1.0 

• Excelsior quiz2 Version 1.0 

• Express Publisher™ Version 2.0 

EdLAN 386 is the same as IBM’s 
existing EdLAN Version 1.10 net¬ 
work package, except EdLAN 386 
includes NetWare from IBM V3.11 
in place of V2.2. EdLAN Version 
1.10 continues to be available. 
LANSchool Version 3.2 is the latest 
release of LANSchool; however, the 
publication content for the present 
version has not changed. 

EdLAN 386 (100 User) enables 
physical access to IBM Classroom 
LAN Administration System Version 
1.40 and NetWare from IBM V3.11 
by up to 100 workstations concurrent¬ 
ly. Use of each of the productivity 
tool programs included in EdLAN 
386 (50 and 100 User) is limited by 
its license terms to a maximum of 50 
machines at any one time (except for 
LANSchool). 

Highlights: 

• NetWare from IBM V3.11 
enhancements include increased 
performance and protection. The 
installation utility greatly improves 
the setup time over previous ver¬ 
sions of NetWare. Startup con¬ 
figuration can be altered easily 
without going through a lengthy 
reconfiguration process. 

• Systems management through the 
use of IBM Classroom LAN 
Administration System Version 

1.40 helps reduce complexity and 
improve productivity for course¬ 
ware and other applications 
management. 

• Comprehensive productivity tools 
include a grade book, test generator, 
spreadsheet, desktop publishing 
capability, word processor, data¬ 
base, and workstation controller. 

• IBM LinkWay Version 2.01 
enables teachers and students to 


design and create text, pictures, 
and graphics presentations. 

Letter # 292-348, June 16,1992 

IBM ActionMedia II Developer’s 
Toolkit Version 1.1 

The ActionMedia™ II Developer’s 
Toolkit Version 1.1 allows applica¬ 
tion and tool developers to become 
more productive in creating Action- 
Media II programs. The Developer’s 
Toolkit provides the same function as 
Version 1.0, with the following addi¬ 
tional features: 

• Executes with Audio-Video 
Kernel 1.1 

• Executes in an OS/2 Version 2.0 
operating environment 

• Executes in a Windows 3.1 
environment 

• Provides sample C source code for 
use in a Windows 3.1 environment 

The Developer’s Toolkit also includes 
the ActionMedia 11 Technical Refer¬ 
ence manual and a programmer’s 
guide. 

The ActionMedia II Developer’s 
Toolkit Version 1.1 Upgrade Kit 
gives users of ActionMedia II Devel¬ 
oper’s Toolkit Version 1.0 the capa¬ 
bility to upgrade to Version 1.1 
without any additional charge. 

Highlights: 

• Source C code and a program¬ 
mer’s guide for use by developers 
to acquire skills in using the 
ActionMedia II Audio-Video 
Kernel programming interface 

• File utilities for developers to edit 
and check the Audio/Video Sup¬ 
port System (AVSS) files created 

Letter # 292-360, June 23,1992 

IBM PS/2 ActionMedia II Upgrade Kits 

IBM announces enhancements to the 
ActionMedia II display adapters and 
offers two ActionMedia II upgrade 


kits. The ActionMedia II display 
adapters include enhanced device 
drivers and programming libraries 
that support a new ActionMedia II 
Audio-Video Kernel programming 
interface. Audio-Video Kernel Ver¬ 
sion 1.1 is provided for use with 
OS/2 Versions 1.3 and 2.0, and Win¬ 
dows 3.1. These ActionMedia II 
multimedia options, part of the Ulti- 
media™ product family from IBM, 
allow the full range of still natural im¬ 
ages, motion video, and quality audio 
information to be incorporated into 
new PS/2 multimedia applications. 

The ActionMedia II Upgrade Kit 1 
includes enhanced device drivers 
(Audio-Video Kernel Version 1.1) 
for use with OS/2 Version 1.3 and 
Windows 3.1. This upgrade kit is 
intended for users who previously 
purchased the ActionMedia II Dis¬ 
play Adapter/A (2 MB) and are using 
the Audio-Video Kernel Version 1.0. 

The ActionMedia II Upgrade Kit 2 
includes enhanced device drivers 
(Audio-Video Kernel Version 1.1) 
and Media Control Interface program¬ 
ming libraries for use with OS/2, 
MMPM/2, and Windows 3.1. This 
upgrade kit is intended for users who 
previously purchased either of the 
ActionMedia II display adapters and 
require upgrading to an OS/2 2.0 
environment, or who wish to use the 
Media Control Interface program¬ 
ming libraries for Windows 3.1. 

Letter # 192-153, June 23,1992 

IBM LAN Distributed Platform 
Programs 

The IBM LAN Distributed Platform 
(LANDP) products provide a client/ 
server distributed programming capa¬ 
bility well suited for applications in a 
LAN environment of mixed operat¬ 
ing systems (DOS, OS/2, and AIX®) 
and mixed machine types (PCs, PS/2s, 
and RISC System/6000s). Clients, 
servers, or a combination of clients 
and/or servers can reside in any 
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machine. A common Application 
Programming Interface (API) across 
platforms and an open design that 
accommodates user-written servers 
also are provided. LANDP/DOS and 
LANDP/2 are introduced with this 
announcement. In the OS/2 environ¬ 
ment, LANDP/2 provides enhanced 
services built upon the OS/2 LAN 
Server, OS/2 LAN Requester, OS/2 
Communications Manager, and OS/2 
Database Manager, through servers 
and a high-level LANDP call API. 


Additionally, LANDP products pro¬ 
vide a significant set of functions, 
application services, and servers to 
facilitate resource sharing, commu¬ 
nications, systems management, 
software distribution, and other sys¬ 
tem and general-purpose functions. 

LANDP evolves from the IBM Finan¬ 
cial Branch Systems Services (FBSS) 
family of products and extends and 
enhances the functionality provided 
by FBSS products. In addition. 


LANDP/2 extends the FBSS/2 Ver¬ 
sion LI functionality from 16-bit 
implementation to 32-bit implementa¬ 
tion for support of OS/2 Version 2.0. 
Mixed LANs including FBSS and 
LANDP workstations are supported, 
and upward compatibility for FBSS 
applications is provided. 

Letter # 292-362, June 23,1992 
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ARCHITECTURE 


Here’s a valuable reference on Micro Channel 
architecture. We’ve collected articles from past 
issues of IBM Personal Systems Technical Solu¬ 
tions and other sources and reprinted them in a 
single publication. 

Focus on Micro Channel Architecture provides 
in-depth technical explanations of the architec¬ 
ture of IBM’s PS/2 Micro Channel systems. A 
foreword by Ramiz Zakhariya, president of 
the Micro Channel Developers Association, is 
testimony to the support of industry leaders. 



♦ ♦ ♦ 


Send me_copies of Focus on Micro Channel Architecture 

at $12.00* plus $3.95 shipping and handling, a total of $15.95* * per copy. 

* Discounts available for multiple copies. 

* * California residents add applicable sales tax. 




□ Charge to my VISA/MasterCard □ Check □ Money Order 

Name: _ 

Company: _ 

Address: _ 

City/State/Zip: _ 

Phone: _ 


VISA/MasterCard #: _ Expires: _/_ 

Make checks payable to: The TDA Group, P.O. Box 1360, Los Altos, CA 
94023■ For faster service, order toll-free by calling (800) 551-2832, or fax 
this form to (415) 948-4280. All orders must be prepaid. 
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